messagegtw probe variables list

[Daniel Blanco]

So I finally got the messagegtw probe working by actually following an IBM's implementation page on how to integrate the messagegtw probe with other products. The current wiki page for the mesagegtw probe has wrong variables listed. I have a case for this and hopefully it gets updated correctly. 

My question is what is the full list of all the message.udata.* and the cs.* variables ? 

On the IBM page the list some of them but I am noticing an issue with certain alerts that don't map properly.
So the IBM page has vars like:

AlertKey = "${message.udata.alarmid}"

appl_id = "${message.udata.prid}"

ClassName = "${message.ClassName}"

Component = "${message.udata.prid}"

ComponentType = "${message.typeName}"

hostname = "${cs.name}"

InstanceId = "${message.InstanceId}"

InstanceSituation = "${message.InstanceSituation}"

InstanceValue = "${ci.name}"

LastOccurence = "${message.LastOccurence}"

msg = "${message.udata.message}"

NodeAlias = "${message.DisplayName}"

origin = "${cs.origin}"

Severity = "${message.udata.level}"

source = "CA_UIM"

SubComponent = "${message.udata.subsys}"

The messagegtw probe wiki lists a bunch of System & Alarm variables, but they didn't specify the object.xxx.var_name  so can't use those.

------------------------------
Daniel Blanco
Enterprise Tools Architect
Alphaserve Technologies
------------------------------

[Daniel Blanco]

Does no one have this list? Anyone, anyone... 

I'm looking for which message.udata.* ones correspond to time of origin and time of arrival. 

I thought all the variables would have matched up with the column headers from the DB table: [NimsoftSLM].[dbo].[NAS_ALARMS] table but when I tried passing 'TimeArrived':'${message.udata.time_arrival}','TimeCreated':'${message.udata.time_origin} those variables didn't get populated.

I have this as my payload:

[

  {

    "source": "CAUIM-ASNYCLAB-MsgGtw",

    "message_key": "${message.udata.alarmid}",

    "resource": "${message.udata.subsys}",

    "node": "${message.udata.robot}",

    "metric_name": "${message.udata.prid}-${message.udata.subsys}",

    "type": "${message.udata.prid}",

    "severity": "${message.udata.level}",

    "description": "${message.udata.message}",

    "additional_info":

"{'ClientName':'${message.udata.hub}','Robot':'${message.udata.robot}','Probe':'${message.udata.prid}',

'ProbeAlertCategory':'${message.udata.subsys}','IPAddress':'${message.udata.source}','AlarmCount':'${message.udata.suppcount}',

'ci.description':'${ci.description}','ci.name':'${ci.name}','ci.type':'${ci.type}','cs.dedicated':'${cs.dedicated}','cs.ip':'${cs.ip}',

'cs.os_description':'${cs.os_description}','cs.os_name':'${cs.os_name}','cs.os_type':'${cs.os_type}','cs.os_version':'${cs.os_version}',

       'TimeArrived':'${message.udata.time_arrival}','TimeCreated':'${message.udata.time_origin}'}"

  }

]

 

This is what the payload populates with:

>> payload: {

"records" : [{"source":"CAUIM-ASNYCLAB-MsgGtw","message_key":"NG60411980-24697","resource":"Disk","node":"as-nyclab-soi",

"metric_name":"cdm-Disk","type":"cdm","severity":"5","description":"DISK - C:\\ is now 146958 MB ( 143.5 GB - 79% ), which is below the threshold 156371 MB ( 153 GB - 85% ) out of total size 179.7 GB ( 100% )",

"additional_info":"{'ClientName':'UIM-NYCLAB_PriHub','Robot':'as-nyclab- soi','Probe':'cdm','ProbeAlertCategory':'Disk','IPAddress':'192.168.241.51','AlarmCount':'1113','ci.description':'System.Disk',

'ci.name':'C:\\','ci.type':'1.1','cs.dedicated':'VirtualMachine','cs.ip':'192.168.241.51','cs.os_description':'Service Pack 0 Build 9600',

'cs.os_name':'WindowsServer-2012-R2','cs.os_type':'Windows','cs.os_version':'6.3.9600','TimeArrived':'','TimeCreated':''}"}]}

 

They are both empty.

------------------------------
Daniel Blanco
Enterprise Tools Architect
Alphaserve Technologies
------------------------------

[Jason Allen]

Hi Dan,

This is largely an educated guess - but I wonder if instead of e.g.

${message.udata.time_origin}

you could try

${message.time_origin}

It has admittedly been awhile since I did much with the internal workings of NAS but as I remember it, "udata" is a section of an alarm with more probe-specific data, whereas time_arrival and time_origin etc are generated by the spooler/NAS based on the actual timestamp of the message when it was sent by the probe/received by NAS/etc.

So I would suspect/guess that these time-related fields are outside of "udata" if that makes sense.  This could be totally off base but I think it's worth looking into...

[Daniel Blanco]

Thanks Jason. I tried that but no luck. 

I tried

• message.time_origin
• alarm.time_origin

I checked the nas manual book from way back in day and that has no references either.


------------------------------
Daniel Blanco
Enterprise Tools Architect
Alphaserve Technologies
------------------------------

[Daniel Blanco]

Got it. Its:
[{"source":"CAUIM-ASNYCLAB-MsgGtw","message_key":"${message.udata.alarmid}","resource":"${message.udata.subsys}","node":"${message.udata.robot}","metric_name":"${message.udata.prid}-${message.udata.subsys}","type":"${message.udata.prid}","severity":"${message.udata.level}","description":"${message.udata.message}","additional_info":"{'ClientName':'${message.udata.hub}','Robot':'${message.udata.robot}','Probe':'${message.udata.prid}','ProbeAlertCategory':'${message.udata.subsys}','IPAddress':'${message.udata.source}','AlarmCount':'${message.udata.suppcount}','ci.description':'${ci.description}','ci.name':'${ci.name}','ci.type':'${ci.type}','cs.dedicated':'${cs.dedicated}','cs.ip':'${cs.ip}','cs.os_description':'${cs.os_description}','cs.os_name':'${cs.os_name}','cs.os_type':'${cs.os_type}','cs.os_version':'${cs.os_version}','TimeOrigin':'${message.udata.nimts}','TimeReceived':'${message.udata.arrival}'}"}]

Results in EPOC time:
'TimeOrigin':'1571258040','TimeReceived':'1571258054'}"}]}


------------------------------
Daniel Blanco
Enterprise Tools Architect
Alphaserve Technologies
------------------------------