Synchronising 2 NNMi Servers (Production and DR)

Synchronising 2 NNMi servers is not simple and straightforward as you would hope/expect.

Unlike HPOM (OML) for example, where you can simple download configuration and upload it again (or in the case of v9.2+ where you can automatically synchronise 2 systems), NNMi doesn't have a neat way to achieve this.

The situation is over complicated with the 2 database options used by NNMi - Oracle and the embedded Postgres database.

According to HP, the Postgres/embedded version has better options for exporting and importing the data to a 2nd server for DR purposes, but using Oracle the solution is far from simple or elegant.  I can't even get a clearly-defined process from HP support which is worrying.

At the moment I am experimenting with the export and import tools, which seems to cover all of the config settings, but at the moment it's reporting errors importing the trap definitions into the DR NNMi server.  This is critical of course, because if the DR server doesn't have the correct trap definitions configured then the alerts won't look the same on the server if we failover or go into DR (disaster recovery) mode.

I'm working with HP support to resolve this, but once again it highlights the poor development of these tools and the lack of adequate and sufficient error reporting.

I'll let you know how I get on.

Dave

NNMi Auto-trimming of Events

Something that caught me out recently was that NNMi has a hard limit of 100,000 alerts.

HP support couldn't give me a definitive answer on what happens when that limit is reached, and experience tells me NNMi doesn't seem to handle this very well, and we have witnessed alerts being dropped rather than some form of round-robin, drop the oldest type functionality...

So, you should definitely configure the NNMi auto-trimming of events functionality as described here.  I have no idea why HP don't have this set in the GUI, or on by default...

This example is on linux:

cd /var/opt/OV/shared/nnm/conf/props

 vi nms-jboss.properties

Uncomment the following line, or copy as I have done, and set to TrimOnly - you can set the archive mode also, just check the required setting and manual to be sure

#!com.hp.nnm.events.snmpTrapAutoTrimSetting=Disabled

com.hp.nnm.events.snmpTrapAutoTrimSetting=TrimOnly

Then set the % of alerts (of the 100k limit) at which the trim operation should start:

#!com.hp.nnm.events.snmpTrapAutoTrimStartPercentage=50

com.hp.nnm.events.snmpTrapAutoTrimStartPercentage=50

Then set the % of alerts to delete during the trim:

#!com.hp.nnm.events.snmpTrapAutoTrimPercentageToDelete=25

com.hp.nnm.events.snmpTrapAutoTrimPercentageToDelete=50

Then run ovstop / ovstart to make the functionality live.

  

Summary:

100k is the hard limit...

Therefore this process starts trimming at 50% (50k)...

It will trim 50% of the alerts, therefore down from 50k to 25k…

Therefore event levels should always be between 25-50k.

That's what I have seen in testing anyway :-)

Alerts owned by NNMi stuck in HPOM

I previously mentioned on the blog (http://tiny.cc/protocolblog) about a strange problem where I see alerts owned in...

Posted by Protocol - Infrastructure Monitoring on Wednesday, 27 January 2016

NNMi alerts owned by opc_adm in HPOM

Have a current weird problem, where I see alerts owned in HPOM by opc_adm due to the web services integration of NNMi with HPOM.

I can't see it documented anywhere (as usual so often with these things!).  HP support are investigating.

If anyone else has any experience of this please share your tips.

Thanks,
Dave