This document describes the procedure to enrich new alarms created by NAS AO profiles.
New alarms generated by NAS via AO profiles do not contain any value in the field dev_id. The impact of this is that they are not visible in USM.
The sections to be added in the nas.cfg are the following (replace the values between <>). Note that the connection URL is for MSSQL.
<enrichment-source>
<cmdbs>
<dev_id>
active = true
connection_url = jdbc:sqlserver://<database_server>:1433;DatabaseName=CA_UIM;
user = <user>
password = <password>
query = select dev_id, dev_name from cm_device where ? in (dev_ip,dev_name)
population_query = select dev_id, dev_name from cm_device where probe_name is not null
</dev_id>
</cmdbs>
</enrichment-source>
<enrichment-rules>
exclusive_enrichment = no
<99>
match_alarm_field = prid
match_alarm_regexp = (nas)
use_enricher = dev_id
lookup_by_alarm_field = udata.source
lookup_by_regexp =
<overwrite-rules>
dev_id = [cmdb.dev_id]
udata.custom_1 = Enriched with dev_id: [cmdb.dev_name]
</overwrite-rules>
</99>
</enrichment-rules>
<routing-rules>
exclusive_routing = no
<1>
active = yes
post_subject = alarm2
condition = true
</1>
</routing-rules>
Another alternative to enrich alarms coming from NAS AO profiles is via LUA script, but this can create additional load, specially when dealing with alarms created from received traps.
It is important to mention that, in some circumstances, we can use the AO action type = "escalate_level" instead of "new_alarm". This will raise the severity of the original alarm while keeping the rest all the fields (including dev_id).