Not working alarm enrichment (NAS)

[Miller Echagarreta]

Hi all.

I appreciate if anyone can help me with this.

I am using alarm enrichment for capturing data in custom field.

I have as enrichment-source for capturing in logmon, pollagent, net_connect probe but I need add other rule with logmon but with enrichment-rule diffrent. 

For some reason, the new rule only work with a alarm(217.x.x.01) and I don't know why doesn't to others.

This is the configuration ----->

<custom_headers>
custom_1 = Comentario
custom_2 = Alias/Responsable
custom_3 = Programado
custom_4 = Entidad
custom_5 = Servicio
</custom_headers>

<VPN>
active = true
connection_url = jdbc:sqlserver://IPDAB:1433;DatabaseName=UIM
user = userUIM
password = xxxxxxxxxxxxx
query = Select RTRIM(LTRIM(comercio)) as comercio from customerasa where PEER in (select replace(supp_key, ',', '') as peer from NAS_ALARMS (nolock) where supp_key =?)
population_query =
</VPN>

<5>
match_alarm_field = prid
match_alarm_regexp = logmon
lookup_by_alarm_field = supp_key
lookup_by_regexp =
use_enricher = VPN
<overwrite-rules>
udata.custom_4 = [cmdb.comercio]
</overwrite-rules>
</5>

This is the alarm(217.x.x.01) that working with alarm enrichment ------>

Captured of key ---->

Query for validate if it's working ----->

The DocNimbus show that alarm enrichment it's working and the custom_4 show the data geted from query ----->

The alarm is working as expected ----->

Now, with this alarm(200.x.x.114) the enrichment-rule not working, not mapping the data in custom_4 as expected.

The query it's working as expected, return the value necessary ----->

Does not put in the alarm the data (custom_4) from alarm enrichment ---->

This problem happen with all Ip less 217.x.x.01, i don't know why, because the logic it's the same for all.

Is possible that 2 enrichment-rules of same (match_alarm_regexp = logmon) naybe cause this behavior?
Has anyone gone through this that can tell me where the problem is?

[Kathy Maguire]

Miller -

I believe that the problem is with your query:

Select RTRIM(LTRIM(comercio)) as comercio from customerasa where PEER in (select replace(supp_key, ',', '') as peer from NAS_ALARMS (nolock) where supp_key =?)

If this is a brand new alarm from the logmon probe with a new supp_key, the alarm will not exist in the NAS_ALARMS table when the alarm_enrichment probe first processes the new alarm.  The alarm_enrichment probe will fail to enrich the alarm so the Custom_4 field will not be populated.  The alarm is then passed on to the nas and at that point it will be added to the NAS_ALARMS table.  If the logmon probe sends another alarm with the same supp_key, as long as the first alarm is not acknowledged (remains active in the NAS_ALARMS table), I would expect the alarm_enrichment probe to match on the supp_key and populate the custom_4 field.  If you are executing the SQL query test after you see that the Custom_4 field is not populated, you are too late because the nas has already added the alarm to the NAS_ALARMS table.

------------------------------
Kathy Maguire
Technical Support Engineer 4
Broadcom
------------------------------

[Miller Echagarreta]

Hi Kathy, thanks for your answer.

The alarms are create from logmon probe with another supp_key, each supp_key are an ip address different.

The supp_key is = 217.x.x.01

Another alarm with supp_key different. 200.x.x.114

[Miller Echagarreta]

Hi Kathy
I solved my problem change the query, not use the nas_alarms table, right now this working.
Thanks.

[Kathy Maguire]

Miller -

Great news!  Your solution seems to confirm my original comment that when the logmon probe creates the first alarm with a new supp_key, that alarm does not exist in the NAS_ALARM table yet so no matches for the supp_key in the new alarm are found in the NAS_ALARMS table and your query returns no results.

The alarm_enrichment probe processes the alarm (to enrich it) before sending it to the nas probe.  The nas probe will then insert a copy of the alarm in the NAS_ALARMS table, but this is after the alarm_enrichment probe tried to enrich the initial alarm.  If the logmon probe generates a second alarm with the same supp_key, and the initial alarm has not been acknowledged, then your original query will find a match for the supp_key in the NAS_ALARMS table and will then successfully enrich the alarm update.

------------------------------
Kathy Maguire
Technical Support Engineer 4
Broadcom
------------------------------