How to add the probe name in an alarm created with nimalarm utility - Example
search cancel

How to add the probe name in an alarm created with nimalarm utility - Example


Article ID: 188864


Updated On:


DX Unified Infrastructure Management (Nimsoft / UIM)


How to add the probe name in an alarm created with nimalarm utility - Example


The process consists of firstly, create an alarm enrichment rule. Then, you will generate the alarm using the nimalarm utility.

In the nimalarm command syntax, you will populate one of the alarm "custom" fields with the probe name you need.

Then, the alarm enrichment rule will get the value provided in that custom field and will populate the "probe" field with the same value.

The example below will use the "custom_4" alarm field.

The alarm enrichment source and rules in the nas.cfg look like this:

active = true
connection_url = jdbc:sqlserver://##.##.##.##:1433;databaseName=CA_UIM
user = sa
password = <password>_encrypted
query = select name,ip,os_type from cm_computer_system where name=?
population_query = select name,ip,os_type from cm_computer_system
exclusive_enrichment = no
match_alarm_field = prid
match_alarm_regexp = (TestAlarmProbe)
use_enricher = dummy_enricher
lookup_by_alarm_field = robot
lookup_by_regexp =
prid = [alarm.udata.custom_4]

Here is the nimalarm syntax:

D:\ca\UIM\bin>nimalarm.exe -l 4 -s <subsystem_id> -S <hostname> -4 MyProbe "Alarm from external source"

This sends a major alarm with "MyProbe" in the custom_4 field.


You must have an active, valid enricher (database connection and query) even if the enrichment rule does not use any of the values returned by the query. The enrichment rules are identified numerically by default (the out of the box example is <1>. You can use actual names for these. When they are numbered, they are evaluated in numerical order, when characters they are evaluated alphabetically. This means you can "stack" these rules so that a subsequent one can override an earlier one based on additional information (matches).


It has to be a valid enricher which means a valid query. A single enricher can be used by multiple enrichment-rules, so it makes sense that it use a potentially useful query. You'll note that there are two queries, the query with the where clause and the population_query. the population_query is run against the database on a defined interval basis and populates memory cache with the result set. The query is run when an incoming alarm matches up with an enrichment-rule and runs against the memory cache result set to minimize overhead on the database and the latency of processing the enrichment.

Additional Information

usage: nimalarm [options] message-string

where options are:

   -l <severity level>
   -s <subsystem id>
   -c <checkpoint id>
   -d <debug level>
   -S <source/hostname>
   -i   return message-id
   -1 <custom1>
   -2 <custom2>
   -3 <custom3>
   -4 <custom4>
   -5 <custom5>
   -t <CI type>
   -n <CI name>
   -m <CI metric>
   -a <alarm token>
   -v <message values e.g. key1=val1;key2=val2...>
   -V   print version