Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT> (459 Views)
Reply
Occasional Advisor
Thomas B. Gudbrandsen
Posts: 7
Registered: ‎02-18-2008
Message 1 of 10 (459 Views)
Accepted Solution

HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

Hi

My company has been using the HP SIM SPI integration beetween HP SIM 5.3 and OMW 8.1 for several months.

The integration itself are working fine, but we are not able to map the events to the agent nodes in the OMW console. The reason beeing that we are monitoring more than 1000 external servers spread beetween 50-100 different domains so a direct mapping beetween hostname and fqhn can't be done by the OMW.

I know there should be parameters/variables on the HP SIM to pass the "network name" to the integration. However I'm unable to find any documentation describing where this can be changed on the integration. Default it's like this:

Severity – Specifies the severity of the message. The severities reported are
normal, warning, minor, major and critical. By default, normal severity
messages are redirected to the acknowledged message browser.
• Node – Name of the node that generates the message. If the message is
forwarded from an HP SIM CMS, then it is the HP SIM server node name.
If the message is generated by an IM Agent trap, then it is the IM Agent
node name.
• Application – Systems Insight Manager
• Object – The system name of the event source.
• Text – A single line description of the event.

I want the <$MSG_OBJECT> to become HP SIMs "Network Name" instead of todays "Preferred System Name" that it seems to be forwarding.

I also need this Network Name for the SM7 integration to work for these events.

Example:
Todays name for a server: dsb-db01 (unable to map)
Required info/name: dsb-db01.dsb.ov3 (mappable by the OMW).

Tried searching the forum, but only found one similar case that wasn't solved, so I'm guessing most of you guys have a setup in a single domain environment.

Anyone got some tips on how to solve this? Have considered using a CMS custom tool on the SIM server to make a new integration but I want to use the finished SPI integration if possible.

Honored Contributor
Atakan Ucar
Posts: 1,189
Registered: ‎01-09-2005
Message 2 of 10 (459 Views)

Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

Hi Thomas,
I dont have a chance to check now, but as i remember <$2> equals the originating node name. So try using <$2> in node name field of SNMP trap policy rules.

Regards
Occasional Advisor
Thomas B. Gudbrandsen
Posts: 7
Registered: ‎02-18-2008
Message 3 of 10 (459 Views)

Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

Hi there

Seems you are using a different type of integration. We have a Open Message Interface policy named "HPSIMInt-HPSIM_Events-Win" running on the HP SIM server. Then some kind of event listener are monitoring a set of event groups on the HP SIM that the SPI tools created:

HPSIMInt_ImportantEvents
HPSIMInt_ApplicationEvents
HPSIMInt_SESRMInfraEvents
HPSIMInt_ClearedEvents
HPSIMInt_ClearedApplicationEvents
HPSIMInt_ClearedSESRMInfraEvents

Somewhere in the SPIs software I'm guessing it runs an opcmsg command with a set of parameters. However I'm unable to find any documentation describing where and how this is done and how I can change the variables that are used from HP SIM.

I guess you are using the integration directly from the IM Agents? I can see SNMP trap policies linked to that way of integrating.

Thanks for the tip tho :)
Frequent Advisor
Roland Koetting
Posts: 29
Registered: ‎10-05-2004
Message 4 of 10 (459 Views)

Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

Your problem is that your omw agent on the machine where your sim eventlistener is running creates opc messages with short node names (dsb-db01). They are not mapped by OMW to your managed nodes (dsb-db01.dsb.ov3).
Try to

1) Add the domain suffix (dsb.ov3) to your OMW server -> IP Settings -> DNS -> Append these DNS suffixes.

2) Check Name Resolution forwards and backwards of this nodename (dsb-db01.dsb.ov3) on OMW server. Must be resolvable (Check DNS?).

3)Finally restart of OMW is necesary because OMW DNS Cache needs a refresh

Occasional Advisor
Thomas B. Gudbrandsen
Posts: 7
Registered: ‎02-18-2008
Message 5 of 10 (459 Views)

Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

Hi Roland

Yeah, you are correct. I'm aware of that beeing the main reason for the shortname not to work. But as I mentioned we are monitoring 50-100 different domains as we are a service provider for around 70 different customers.

I want to try to avoid adding every single domain as a DNS suffix. Both forward and backward resolutions are working for the .dsb.ov3 names. In addition we have the same structure on the DNS for other customers, .spv.ov3, .nammo.ov3 etc.

For the IBM Systems Director integration and other integrations like NNMi 9 and Nagios we are using these FQHN from the DNS, so a mapping to the OMW nodes are easily beeing done by the OMW.

HP SIM is the only product where we haven't found a way so far to pass the "network name". If we are able to send the .dsb.ov3 etc names with the integration everything would be solved.

If not then a workaround with adding every single domain suffix into the DNS can be done, but I'm not sure that is a good idea.

Many thanks for the tip tho, I have considered that solution myself, but I want to send the network name with the integration instead if it's possible.
Frequent Advisor
Roland Koetting
Posts: 29
Registered: ‎10-05-2004
Message 6 of 10 (459 Views)

Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

OK,

what I often did here is throwing this complicated integration away and just log the raw event parameters into a logfile on SIM server as an alternate task for the sim integration eventcollections (instead of calling the websevice...

Here you just need an agent on SIM Server and some conditions for your logfile policy. But then you definiteley will be able to log your FQDN network name (DEVICE=dsb-db01.dsb.ov3).

Occasional Advisor
Thomas B. Gudbrandsen
Posts: 7
Registered: ‎02-18-2008
Message 7 of 10 (459 Views)

Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

Thanks again.

I tried doing something similar myself. Logging the HP SIM events to the windows eventlog. My idea was then to catch the information from the eventlog later on.

Made a Automatic Event Handling Task like this:

Task name: Write to Application Eventlog
Owner: MGMT\administrator
Time filter: None defined
Event collection: HPSIMInt_ImportantEvents
Event category is not General Backup
Event category is not Systems Insight Manager Events
severity is Critical
severity is Major
severity is Minor
severity is Warning
System collection: All Systems
All Systems
Action(s):
Write to system log


The problem here was that the event generated in eventlog doesn't include the network/fqhn either.

dsb-db01: (SNMP) Generic trap (11003):
Event Name: (SNMP) Generic trap (11003)
URL: https://217.18.194.152:2381/
Event originator: dsb-db01
Event Severity: Major
Event received: 15-Jul-2010, 09:10:35

Event description: Generic trap.

Text: Management Agents Test Trap sent - Thursday, July 15, 2010 9:10:34 AM

How did you solve the logging of the additional information?
Frequent Advisor
Roland Koetting
Posts: 29
Registered: ‎10-05-2004
Message 8 of 10 (459 Views)

Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

Define a tool in SIM that logs a line to a file like this and use it as an eventtask:

cmd /C echo %%NOTICESTATE%%:%%NOTICEPLAINTEXT%%:%%NOTICERAWDATA%% >> c:\SIMeventlog.txt

This should provide more details than you need

Have fun!
Roland
Occasional Advisor
Thomas B. Gudbrandsen
Posts: 7
Registered: ‎02-18-2008
Message 9 of 10 (459 Views)

Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

Many thanks.

Worked fine and confirmed the DEVICE=dsb-db01.dsb.ov3 in the log ;)

Now to start working on a good policy to catch this information.

The case is solved by doing a different approach on the integration. Will keep the post alive a couple days to see if anyone got a fix to the initial SPI integration. If not then this should be the recommended solution for others in my situation.
Occasional Advisor
Thomas B. Gudbrandsen
Posts: 7
Registered: ‎02-18-2008
Message 10 of 10 (459 Views)

Re: HP SIM-OMW integration - Get "network name" as <$MSG_OBJECT>

Hi, will give you all a chance for some extra points aswell. The variables I'm making for the policy are not beeing nice to me.

The original logfile line are like this:
2:"|Event Name: (SNMP) Generic trap (11003)|URL: https://195.254.192.132:2381/|Event originator: dsb-db01|Event Severity: Major|Event received: 15-Jul-2010, 10:26:12| |Event description: Generic trap.| |Text: Management Agents Test Trap sent - 15. juli 2010 10:26:11|":"NOTICE_ID=82033|NOTICE_TYPE=8059|DEVICE_KEY=3|TRAP_ENT_OID=1.3.6.1.4.1.232|1.3.6.1.2.1.1.5.0=dsb-db01|1.3.6.1.4.1.232.11.2.8.1.0=Management Agents Test Trap sent - 15. juli 2010 10:26:11|1.3.6.1.4.1.232.11.2.11.1.0=0|NOTICE_TYPE_STR=Trap.cpqHo2GenericTrap|NOTICE_STATE=2|NOTICE_SEVERITY=Major|TRAP_SPECIFIC_ID=11003|DEVICE=dsb-db01.dsb.ov3|TRAP_GENERIC_ID=6|GENERATED=Thu, 7/15/2010, 10:26 AM CEST"

I have made the following rule on the logfile policy to trigger and generate a set of variables for later use in the message:

<*>URL: <*.url>|<*>|Event Severity: <*.severity>|Event received: <*.time>|<*>|Event description: <*.description>|<*>|Text: <*.text>|<*>|NOTICE_TYPE_STR=<*.type>|<*>|DEVICE=<*.device>|<*>

The policy triggers just fine, but for some reason the output message looks like this:

"
HP SIM reports the following error:


Full text:


Affected server:
Servers homepage:
HP SIM: https://p-100-287-043:50000
"

Used this approach on several Open Message Interface policies earlier, and from the help document the same thing should be doable for logfile policies. Are there something I'm missing?

should have contained "Generic trap." etc.

Guess it's just to close to the summer vacation, so I'm missing some basic stuff. Any tips?
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.