DX Unified Infrastructure Management

Hi All

We have setup CA_UIM to receive alarms from an other monitoting system also.

These alarms are submitted using webrest "rest/alarms/createAlarm".

All alarms appearing are in NAS, so far this works.

BUT not one alarm is shown in USM.How can these Alarms been shown in USM?  What is missing?

Thanks.

Daniel

********************************************************************************************
********************************************************************************************

JSON used to submit alarms:

my $host = 'http://<NIMSOFT>/rest/alarms/createAlarm';

my $user = 'USER;

my $pwd = 'Password';

  my %request_body_map = (

    'assignedBy'=>'',

    'assignedTo'=>'',

    'custom1'=>'',

    'custom2'=>'',

    'custom3'=>'',

    'custom4'=>'',

    'custom5'=>'',

    'devId'=>'',

    'domain'=>'',

    'hostname'=>'',

    'hub'=>'',

    'level'=>$level,

    'message'=>$source . ": " . $message,

    'metId'=>'',

    'nas'=>'',

    'origin'=>'',

    'prevLevel'=>'',

    'probe'=>'',

    'robot'=>'',

    'severity'=>$severity,

    'source'=>$source,

    'subsystem'=>'',

    'subsystemId'=>$subsys,

    'suppressionCount'=>'',

    'suppressionKey'=>$supp_key,

    'visible'=>'true',

    );

********************************************************************************************

********************************************************************************************

Hi there, you need to populate the Met_Id and Dev_Id of the device for it to show in USM.

You should be able to see the alarms in the alarm console within USM (stopwatch icon)

cheers

Thanks for your reply.

I found all alarms using the "stopwatch icon" which I did not know before.

So there are only no alarms shown in groups.

Which would also be great to achieve.

Daniel

HI
I looked into it but I'm unable to figure out what met_id is used for or where it comes from.
Can you enlighten me?

Daniel

Daniel,

the Metric_id is created by the probe creating the alarm and the Device_Id usually comes from the robot.

so you need to find the device in UIM and use the correct dev_id and met_id in your alarm.

If its external system then you need to use cm_data_import to create the correct details in the database so that USM can display the device and then you can use those dev_id's to assign the alarms to that device.

hope that helps

cheers

Hi Rowan
If I understand this right, I have to populate the database with external devices and making queries to get met_id and dev_id just to be able to display alarms in groups event if the needed grouping item is already there?

Daniel

If the device is already there then you don't need to do it again. That is the process for new external devices, someone else may have more practical experience...

Using the dev_id on its own might be sufficient (ie blank met_id) for USM to display. I would need to test it to see.

If the device you're sending an alarm about is already being monitored with UIM then the dev_id will be already in the DB (cm_device table), you might be able to get that using REST/CI.

Thanks Rowan
I have to go into it and do some investigation.

Thanks for helping me.

Daniel

Hello,

I think I posted to the wrong thread. My current understanding is that dev_id is required for correlation

but metric id is not:

USM to support alarm from other source then dev_id

However, the fact that the the tree symbol remains green may indicate my understanding

is flawed. Try it with "test_alarm" callback of the controller probe of any robot.

(In Web Admin Csonsole - > Robot -> Controller -> Probe Utilities -> test_alarm in the dropdown list)

Alexei

Hi
I have checked this, test_alarms are showing correctly. Thanks.
I am about to suspect that the USM is buggy.
We had already once a similar problem when grouping by "origin" did not work. Then we got a HF and shortly after this the ugs-probe 8.35 was released which fixed it.
Why do I suspect the system may be buggy?
Because sometimes the alarms are showing up for a few seconds before they disapear again.
The Picture I've taken are just a few seconds apart.

Daniel

To be precise. I was trying to emulate "test_alarm" by stealing its subsystem ID and suppression key

while adding enough device specific information to properly correlate alarms.

This Clojure code is executed on a linux host and posts alarms with the robot device id and the IP

of a windows host:

(defn- send-alarm [level message]

  (let [alarm (doto (NimAlarm. level message)

                ;; Numeric ID is expected. Reverse lookup does not

                ;; happen:

                (.setSubSystem "1.2.2.1") ; 1.2.2.1 = Controller

                (.setSuppressionId "test_alarm")

                (.setDevId "Dxxxxxxxxxxxx") ; windows "robot device id"

                (.setSource "10.20.30.40"))] ; windows robot IP

    (.send alarm)))

The alarm is shown in the USM bar plot and in the list view below that bar plot

of the tree node corresponding to the windows host. But the tree symbol and

the the icon on the details tab in USM remain green.

Also the SQL table NAS_ALARMS contains the row with robot dev_id, source, and hostname

of the windows host. The robot name is that of linux host, the met_id is NULL.

What am I doing wrong?

I dont seem to grasp this source/target + robot/source + device/configuration/metric staff

to get it. Can anyone advise?

Alexei

So I tried to reproduce the behavior with "createAlarm" via webservices_rest (v2.19 on UIM v8.31)

and found this:

1) The "devId"  field of the JSON POST body does not make it to NAS_ALARMS Table at all.

I also do not see it on the bus while sniffing at the hub. The webservices_rest runs on UMP

node which is different from the hub. Assuming Dr NimBus shows all the details the "devId"

field is likely ignored by the webservices_rest probe. This behaviour is different with Java API

where a call to setDeviceId did have an effect of populating the respective  NAS_ALARMS column.

2) Neither integer nor strings are accepted for the numeric severity "level" field.

I need to specify "severity" field in symbolic (word) form: "Critical", "Major", etc.

3) domain, hub, origin, and robot fields appear to be overwritten by the probe.

Also specifying arbitrary value in the "nas" field had no observable effect.

4) "Source" field is translated and overwrites "hostname", reverse-resolved even if specified as IP.

5) Custom fields propagate properly.

Without known device id the alarms are shown in the alarm console (clock icon) but not on the

tabs of tree node.

Is this the expected behavior?

Alexei

Hi Alexei
You're right, this is the odd behaviour of webservices_rest 2.19.
I tried to manipulate the dev_id directly in the database by updating the field manually. But this did not change the green icon.

Maybe the dev_id could alse be set using alarm_enrichment. Still, I don't see a reason why the tree does not show whats available already.
I still belive its a bug within the system.

UIM 8.40 does not use ugs anymore - maybe the problem is solved.

Thanks for helping out investigating the issue.

Daniel

No progress with REST API, but for the Java API I was only able to get the results with

freshly generated RemoteDevice, ConfigurationItem, and Metric generated in that order:

Metric refers to CI, CI refers to device. Moreover The RemoteDevice seems to be linked to the robot

it was generated at (maybe only the MD5 hashes are linked?). Below is some code with

comments.

So far I was not able to post alarms using existing Metrics/CI/Devices created by

other probes.

;;

;; The metric  is linked  to a  CI and  that is  linked to  a (remote)

;; device with associated IP and a  host name.  However if you rely on

;; that and forget to supply the  source in addition to the device ID,

;; the source  will be  set to  the robot IP.   That does  not prevent

;; correlation with the  remote device to happen -- the  alarm will be

;; displayed  in the  USM  at  the tree  node  of  the remote  device.

;; However, and this  is very confusing, the very  first (bold) "host"

;; name that you see in the alarm  list view is that of the robot host

;; -- the  host name derived by  reverse lookup of the  source IP, not

;; the actual robot  name which is also available with  each alarm. So

;; for best results you  also need to set the source to  the IP of the

;; remote device in addition to the device ID you supplied.

;;

(defn- send-alarm! [level message source device-id metric-id]

  (let [alarm (doto (NimAlarm. level message)

                ;; Numeric  ID is  expected. Reverse  lookup does  not

                ;; happen. If the symbolic name is unknown the numeric

                ;; path is used instead.

                (.setSubSystem "9.9")   ; "Test CI", not in DB

                ;; (.setSubSystem "1.2.2.1") ; 1.2.2.1 = Controller

                (.setSuppressionId "test_alarm")

                (.setSource source)

                ;; If you only supply device ID the source will NOT be

                ;; derived from it:

                (.setDevId device-id)

                ;; If you only supply the metric ID the subsystem and

                ;; the device will NOT be derived from that:

                (.setMetId metric-id))]

    ;; The confirmation ID returned by send  is not the same as in the

    ;; NAS_ALARM table of the SQL server (FIXME: there are also sqlite

    ;; tables in nas probe dir):

    (.send alarm)))

Correction:

2) The "severity" field accepts numeric values as integers or strings in addition to keywords.

   The purpose of the "level" field is unclear.

For anyone else looking at this thread i have managed to get a "workaround" working in my environment and am creating alarms via REST webservices.

Have a look at this thread for more info: REST webservices devId and metId

HI, thanks for the post. I'd like to get a view on it, but get only access denied when clicking the link.
Daniel

Here you go Daniel.  I put together an example using web services to create an alarm which with a little alarm enrichment updated the devId and therefore my alarm now shows in the USM groups as shown in the screenshot below:

Here is a screenshot showing the devId from Dr Nimbus on alarm2:

Here is the section content from my nas.cfg file which contains the lookup info.  The cmdbs section needs to be updated to point to your UIM DB with a valid JDBC connection string.  Enter the password in plain text and on first use it will be automatically encrypted.  In my example my SQL statement returns only devices which have robots on them.  Adjust if required for your environment.

<enrichment-source>

  <cmdbs>

      <dev_id>

        active = true

        connection_url = jdbc:mysql://192.168.61.134:3306/ca_uim

        user = root

        password = yOG1MB/vAFJfBU7ugLIt+Q==_encrypted

        query = select dev_id, dev_name from cm_device where probe_name='controller' and dev_name=?

        population_query = select dev_id, dev_name from cm_device where probe_name='controller'

      </dev_id>

  </cmdbs>

</enrichment-source>

<enrichment-rules>

  exclusive_enrichment = no

  <1>

      match_alarm_field = prid

      match_alarm_regexp = wasp

      use_enricher = dev_id

      lookup_by_alarm_field = robot

      lookup_by_regexp =

      <overwrite-rules>

        dev_id = [cmdb.dev_id]

        udata.custom_3 = James Enriched

      </overwrite-rules>

  </1>

</enrichment-rules>

<routing-rules>

  exclusive_routing = no

  <1>

      active = yes

      post_subject = alarm2

      condition = true

  </1>

  <2>

      active = yes

      post_subject = /setup/storm_subject

      condition = true

  </2>

</routing-rules>

For testing i used CURL on Linux to post to webservices my json payload like this:

curl -v -H "Accept: application/json" -H "Content-Type: application/json" -X POST --data @alarm.json -uadministrator:CAdemo123 http://jamesump/rest/alarms/createAlarm

Here is the content in my alarm.json

{

    "assignedBy":"",

    "assignedTo":"",

    "custom1":"",

    "devId":"",

    "domain":"james_domain",

    "hostname":"jamesump",

    "hub":"jamescore_hub",

    "level":"1",

    "message":"James Test message",

    "metId":"",

    "nas":"jamescore_hub",

    "origin":"jamescore_hub",

    "prevLevel":"0",

    "probe":"",

    "robot":"jamesump",

    "severity":"Major",

    "source":"jamesump",

    "subsystem":"Nimsoft",

    "subsystemId":"1",

    "suppressionCount":"0",

    "suppressionKey":"jamestest",

    "visible":"true"

}

Regards

James

Aw, great. Thanks James.

Daniel

Yeah! This is it. U really helped me with this solution.

Thank you.

Daniel