UIM Alarms in OC do not associate with a device

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

UIM alarms generated by a remote probe (such as rsp, url_response, snmptd, etc) are not being associated to the proper device in Operator Console.  

Without this correlation, the Device Details in OC are missing (yellow highlight):

 

It is expected to see Device Details as highlighted below:

Environment

• UIM 20.4+

Cause

This is caused by the remote probe going through one hub (origin) and the device being monitored is also a robot that is reporting to another hub (origin).  In this situation, the Device/Origin combination for the alarm does not match the Device/Origin recorded for the device.  Therefore, the alarm is not correlated to the device.

Resolution

The following workaround will update the alarm with the robot origin configured in CM_COMPUTER_SYSTEM and CM_NIMBUS_ROBOT tables in the database.  These steps document changes to be made in the nas.cfg file.  (An article in the Additional Information section below describes using Raw Configure to make similar changes.)

 

1. Identify the subsystem used by the alarms.  This is found in the Alarm Details in Infrastructure Manager.  Please note that this subsystem will be used as a filter.  The change of origin will be applied to all alarms with this subsystem.  For example, the snmptd probe uses subsys = "1.1.3.".  The nas.cfg lists all subsystem and identifies this as "Network".  The example below will use this subsystem.
   
   
2. Locate the "enrichment-source/cmdbs" section in the nas.cfg file.  Create a new section named "origin_update" under this section.  Be sure to properly enter the sqlserver_ip_address, db_user, and password (highlighted in the example below).  The password will be encrypted when the probe restarts. 
   

   <enrichment-source>
      <cmdbs>
          ...
         <origin_update>
           active = yes
           connection_url = jdbc:sqlserver://<sqlserver_ip_address>:1433;DatabaseName=CA_UIM;
           query = SELECT robot, origin FROM CM_NIMBUS_ROBOT where robot=?
           population_query = SELECT robot, origin FROM CM_NIMBUS_ROBOT
           user = <db_user>
           password = <password>
       </origin_update>
        ....
      </cmdbs>
   </enrichment-source>

   
   
   • Note that the connection_url used in the example above is for MSSQL.
     • Oracle DB example:
       connection_url = jdbc:oracle:thin:@//<ip address>:1521/ca_uim
     • mysql DB example:
       connection_url = jdbc:mysql://<ip address>:3306/ca_uim
3. Locate the "enrichment-rules" section in the nas.cfg file.  This section will have other sections that are named with numbers.  Create a new section using the next number in the sequence (highlighted in the example).  Note the match_alarm_regexp key has the subsys that will be used to filter the alarms.  Update this with the subsystem that you wish to use as a filter (also highlighted in the example).
   

   <enrichment-rules>
       ...
      <#>
        match_alarm_field = udata.subsys
        match_alarm_regexp = 1.1.3
        use_enricher = origin_update
        lookup_by_alarm_field = robot
        lookup_by_regexp =
            <overwrite-rules>
                origin = [cmdb.origin]
            </overwrite-rules>
      </#>
       ...
   </enrichment-rules>

4. Save the nas.cfg file and then restart the nas probe.
5. Clear any existing alarms and watch for new alarms to come in and be properly correlated with the device.

 

Additional Information

This resolution is similar to that described in the following article.  This article provides an example to make similar changes using Raw Configuration:

How to update origin for robot inactive alarm