How to monitor OCUM itself running status (both for 5.2 and 6.1)?

[chao]

Customer care about OCUM itself health because OCUM take key role to monitor all storage status,  raise alarm.   So customer want to know how to monitor OCUM itself running status except monitoring the server which OCUM stay.

[kirana]

Hi Chao,

For OCUM6.x,  the Vsphere 'application aware APIs' are not yet integrated into OCUM.

Below link has more details on AAA APIs:

http://www.virtuallyghetto.com/2011/08/new-application-awareness-api-in.html

Of course this isn't ready in OCUM6.x  as yet.  You can contact product management if its in the road-map.

I am not sure about UM5.x side of the story.

[venkat3]

Hi Chao,

Adding to what kiran said.

Since OCUM6.1 is a VM , for now you can configure VMware Alarms for the VM to check the health of VM.

-Srinivas

[arunchak]

Exactly! I was about to emphasize on what venkat3 mentioned. You need to monitor the VM using VMware alerts.

In UM5.x you have an option of installing the core package on MSCS or VCS HA clustering solutions so that your OCUM server is safer than what it would be on a standalone box. You can consider this option too.

Thanks,

  Arun

[chao]

thanks a lot for your kindly reply.  this is 7+C mixed environment so customer may want to still use OCUM 5.2R1 to monitor 7 and C(8.2.1).  if using OCUM 5.2r1,  even we setup MSCS or VCS HA,  it could still not avoid application-level failure (ex, hung).  

[chao]

VM alarm could take care VM level issue but customer worry about if OCUM itself is hung or no responding by any reason

[nitish]

Hi Chao,

Were you able to find a solution?

My customer wants to monitor the OCUM vAPP's health via SNMP. 

[JTVNETAPP]

Assuming the goal is to monitor the DFM services, I've setup the following in our environment:

OnCommand 5.2 running on Windows:
batch file to echo date to file (e.g. dfm.service.list). dfm.service.list is stored in DFM's webserver root directory.
Then pipe the output of "dfm service list" to dfm.service.list.
In our environment a daily run is sufficient.

On a remote box (in my case linux):
I wget dfm.service.list from the DFM webserver, and then check to make sure the date is current and each service is "running".
If DFM is down or DFM server is hung or down the wget will fail and the script will email/alert/page as appropriate. Same is true if one of the DFM services is not "running".

While a daily check is sufficent for us, if DFM is more important in yours you could run the 'dfm service list' script more frequently, and echo the time + date. Then have the remote box with the checking script compare time stamp, and be sure it is within ## minutes/hours of current time.