alarm enrichment of user_tag_1 and user_tag_2 failing

[Anon Anon]

We recently upgraded to NMS 6.5 and discovered that the alarm enrichment probe got incorporated into the nas.

 

So reconfigured the nas to enrich.  We can get custom_1 through custom_5 to enrich with new data from our enrichment database.  However, no matter what we do, user_tag_1 and 2 will not enrich with anything.

 

Here is the nas config:

 

<enrichment-source>
<cmdbs>
<alarm_enrichment>
   active = true
   connection_url = jdbc:sqlserver://<some_server>:<Port_number>;DatabaseName=NimsoftSLM
   user = nimsoft_install
   password = <Encryptd password>
   query = select hostname as id, hostname, kbid, rto, application from MGI_Alarm_Enrichment where hostname = ?
   population_query = select hostname as id, hostname, kbid, rto, application from MGI_Alarm_Enrichment
</alarm_enrichment>

.

.

.

<enrichment-rules>
   exclusive_enrichment = no
<1>
   match_alarm_field = prid
   match_alarm_regexp = (url_response|dns_response)
   use_enricher = alarm_enrichment
   lookup_by_alarm_field = udata.source
   lookup_by_regexp =
      <overwrite-rules>
         udata.user_tag_1 = [cmdb.hostname]
         udata.user_tag_2 = [cmdb.rto]
         udata.custom_2 = [cmdb.hostname]
         udata.custom_3 = [cmdb.application]
         udata.custom_5 = [cmdb.kbid]
     </overwrite-rules>
</1>

 

 

I have tried changing the overwrite rules to use just user_tag_1, user_tag1, and udata.user_tag1 w/o success.

Support doesn't seem to know what is happening either.

 

The old alarm enrichment probe that we got from proffessional services worked perfectly if we used user_tag_1 and user_tag_2 in the overwritew rules.  Not sure what is going on with the new enrichment probe.

[Anon Anon]

Figured it out.  As it turns out, the documentation of the nas 4.20 is wrong for enrichment.

 

The enrichment rules should look like this:

 

<enrichment-rules>
   exclusive_enrichment = no
<1>
   match_alarm_field = prid
   match_alarm_regexp = (url_response|dns_response)
   use_enricher = alarm_enrichment
   lookup_by_alarm_field = udata.source
   lookup_by_regexp =
      <overwrite-rules>
         user_tag_1 = [cmdb.hostname]
         user_tag_2 = [cmdb.rto]
         udata.custom_2 = [cmdb.hostname]
         udata.custom_3 = [cmdb.application]
         udata.custom_5 = [cmdb.kbid]
     </overwrite-rules>
</1>

 

User tages do not live under udata as is shown in the example in the documentation.

 

Also, when testing, make sure to acknowledge all open alarms.  Only new alarms will enrich the user tags properly.

[Anon Anon]

Would just like to say in this context that I and some other people have had some stability issues with alarm_enrichment in 6.5, which prevents alarms from being generating. I would keep a close eye on the alarm_enrichment queue and maybe create external monitoring for it.

 

-jon

[Anon Anon]

Thanks, Jon.

I saw that thread.

It's rather sad to see this issue since the original stand alone alarm enrichment probe was quite stable.

[Anon Anon]

Let me know if you see an issues where it populates some of the data fields even if their is nothing returned from the cmdb lookup query.  I have seen cases where the device don't exist in my query but it would somehow populate custom fields with data from another device.  This only seems to happen when a device is not in the population/lookup query.

[Anon Anon]

As I recall, the original alarm enrichment probe was very finicky with its config. Supply a wrong password or a bad query and it would crash with no message as to why. I wonder if some of the issue may be related to bad DB queries in the config. Or even enabling a CMDB that didn't exist would bomb the probe. Really, error handling could be much improved with this probe.

So far so good for us running it for a week against two DB enrichment tables. Everything has been accurate so far with hundreds of enrichments happening per day. Knock on wood!