The customer was facing the problem that he needed to change the source in the logmon probe. He noticed that if he filled the "Source" field and created an alarm, that this alarm is seen on the server (robot) where the alarm was created with the source information of the new source. The problem is with DEV_ID at the alarm side, this DEV_ID is not the source ID, but the robot ID. This can be verified by looking at the alarm via Dr.Nimbus.
The requirement was to have these alarms to be attached to the source device in order to see these alarms under the correct entry in the USM.
At this moment, that is how the probe operates. It does change the source but not the dev_id for the custom alarm, it will still come under the dev_id of the robot.
However, it should be possible to later change the dev_id via the alarm_enrichment probe to match the dev_id of the desired device.
For information about how to set up alarm enrichment itself, please review the information under "Additional Information".
The idea here is that you set up an \enrichment-source\cmdbs\os_enricher section in alarm_enrichment. The lookup would then be done via source (or udata,source, you would need to verify this field via dr.nimbus).
A viable query to find the devices would be something like 'select dev_id, dev_name as name from CM_DEVICE where name=?' .
After that the mapping and substitution could be build through the overwrite-rules section with:
match_alarm_field = prid
match_alarm_regexp = logmon
lookup_by_alarm_field = source (or udata.source)
key = dev_id
value = [cmdb.dev_id]
The basic explanation of alarm_enrichment can be found here:
Also, this is a very good thread on the community that explains a bit more about the functionality of alarm enrichment: