I have a situation where only alarm2 message is pass to our environment and discovery is limited or block.
Information of alarm will not display in USM group It can only be view through the alarm console.
This has cause two scenario I observe when trying to overcome this problem.
1. Discovery_server with help of discovery_agent manage to gather information for the devices by icmp but the device's alarm are not map to the USM host.
2. Data imported through cm_data_import to bulid a device in the USM alarm are not map to it.
I have read through Imported alarms not shown in USM and it seem possible.
I would like to know how can I enrich alarm2 so that I can alter the alarm's dev_id to the ones in the USM group I have build discovery_agent and cm_data_import.
I assume that you have a remote NAS that is forwarding this "alarm2" message?
You could change that remote nas to generate this "alarm2" as "alarmxx"
Once your "alarmxx" is arriving on your main nas you can customize that nas to receive not only "alarm", but also "alarmxx". This way it will pass also the enrichment customization that you are referring to.
Most likely some how what you describe of the alarm routing.
Currently only a main nas that does the nis_bridge subscribe to alarm2 routed out by its alarm_enrichment and alarm2 that is from a hub queue of alarm2 subject from other remote hub that I can't modify.
It would be good that the remote nas configuration can change to alarmXX and use the route you describe above.
Backup plans is deploy another secondary nas in our environment and use its alarm_enrichment to deal with alarm2 to change the dev_id and route out as alarmXX then the main nas alarmXX only instead of default alarm2.
Even worst case make main nas alarm_enrichment accept alarm,alarm2 and make main nas accept only alarmXX.
A double job for main nas alarm_enrichment.
This should allow change of dev_id through article information in Imported alarms not shown in USM to map to existing dev_id in the cm_device so it map to Cm_computer_system and display in USM.
Tried main nas alarm_enrichment to handle alarm,alarm2 subject and nas accept alarm3.It seem to show alarm_enrichment cannot handle alarm2. From alarm_enrichment log shows me "AlarmQueueReader: Unexpected message subject recieved: alarm md5sum=....,nimts=15387000917,,tz_offset=28800,dev_id=D672...,subject=alarm,hop0=...,hop1=...,origin=...,charset=UTF-8,prid=clariion,robot=...,suppression=y+00000000#....,prid=0,udata:message=... is now responding,level=0,source=....,subsys=2.14.2
Did you change in nas.cfg also:
post_subject = alarm2
Into something else? (like alarm3)
Yes change to post_subject = alarm2 to alarm3.
Saw hub alarm_enrichment queue changes to alarm,alarm2. nas queue is alarm3 before I change back to original which is alarm_enrichment queue alarm subject and nas queue is alarm2 subject.
Only thing is I never do a complete start stop of both alarm_enrichemnt and nas.
Afterwards a few hours later notice saw alarm_enrichment queue building up did a full start stop and queue building up cleared.
When you change something in nas.cfg, you need always a restart of alarm_enrichment and nas to activate your changes.
Devices imported in with cm_data_import will be in Cm_computer_system but will not have a corresponding cm_device entry and as such no dev_id.
The reason alarms show in alarm console but not in USM is because they are missing a valid dev_id to map them to a specific device.
If the alarm is coming from somthing such as net_conning or icmp using the discovery agent from the hub where the probe is running will usually add enough information into the local niscache and database to allow the alarm correlation to happen.
If the alarms are coming in say from snmptd that and no other monitoring of the device is being done by UIM than you will probably not be able to make this work.
Alarm2 alarms come from either replication or from alarm_enrichment.
The only way you have access to the dev_id to update it is using alarm_enrichment, as alarm_enrichment can update any field in the alarm. Pre-processing and AO only have a subset of feilds they can modify.
But if a valid dev_id does not exist is the system with a matching cm_computer_system entry then you will not be able to get a proper mapping.
Hope this helps exlplain.,
Thanks for the information. I didn't knew cm_data_import create only cm_computer_system entries but not cm_device entries that is important for USM alarm mappings.