07-14-2010 04:17 AM
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
• 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.
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.
Solved! Go to Solution.
07-14-2010 08:56 AM
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.
07-14-2010 10:05 PM
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:
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 :)
07-14-2010 10:27 PM
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
07-14-2010 10:44 PM
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.
07-14-2010 10:53 PM
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).
07-14-2010 11:16 PM
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
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
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)
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?
07-14-2010 11:22 PM
cmd /C echo %%NOTICESTATE%%:%%NOTICEPLAINTEXT%%:%%NOTICERAWDAT
This should provide more details than you need
07-14-2010 11:36 PM
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.
07-15-2010 12:43 AM
The original logfile line are like this:
2:"|Event Name: (SNMP) Generic trap (11003)|URL: https://184.108.40.206: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|DEVIC
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=<
The policy triggers just fine, but for some reason the output message looks like this:
HP SIM reports the following error:
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?
Guess it's just to close to the summer vacation, so I'm missing some basic stuff. Any tips?