opctrapi

How to control opctrapi behaviour?

Run the NNM test tool eA.ovpl shows that a very high number of authentication traps coming in from a few different devices: You can configure trapd.conf to drop the event before it's passed to pmd so it's not even processed. This would be my recommendation as it saves unnecessary processing.

+--------+

| netmon |

+--------+

|

\|/

+---------+ +-----+ +----------+

SNMP -> | ovtrapd | | pmd | | opctrapi |

+---------+ +-----+ +----------+

|

X suppress SNMP here by modifying trapd.conf

ovevents from netmon will still arrive as they

are not sent through ovtrapd.

This is the best way to remove events, as the event is not even processed by pmd. This will only suppress SNMP events, not events generated by netmon (or ovevents). If events are maked as LOGONLY in trapd.conf, in most cases these can also be dropped as they are never really needed.

If the events are needed by NNM, but not OVO, these events can either be suppressed as opctrapi connects SNMP_EVENT_LIST (1) can be used as an event filter.

+--------+

| netmon |

+--------+

|

\|/

+---------+ +-----+ (2)+----------+

SNMP->| ovtrapd |--->| pmd |--->| opctrapi |---> OMU Server

+---------+ +-----+ +----------+

/|\ /

|______/ (1)

The event is not sent to opctrapi in the first place (2). SNMP_EVENT_LIST can only be switched in/out depending running ovconfchg. ovevents can also be suppressed using SNMP_EVENT_LIST.

pmd QEvent/logStats options:

This is because of the two options which you can use - QEVENT and logStats which will help in understanding event flow. In order to use both options, they need to be defined which is why "0:pmd:pmd:OVs_YES_START::-SOV_EVENT;J"QEvent%1000@250@300^logStats%1000@10":OVs_WELL_BEHAVED:30:PAUSE::" was suggested so I can use these new options to help see how pmd/opctrapi is performing. Below are the knowledge documents which I was referring to in my earlier emails. The logStats option is going to be less useful, but interesting never the less.

KM544616 New QEvent J option in ov_event IP21

The new "J" option (QEvent) allows pmd to be configured to issue an alarm that alerts operators when an application attached to pmd is having messages queued on its event socket. Queued events can cause pmd to grow in memory size and can indicate a hung application. Certain HP applications will not be aborted when the queue size reaches the default limit, causing the queue to grow larger until pmd cannot allocate any more memory resulting in a crash.

The new option can be configured with a threshold value, an incremental value and a time period using the following format:

J"QEvent%<threshold>@<incremental>@<timePeriod>"

When the number of events in the queue is greater than the threshold value, pmd will issue an alarm, OV_PMDAppQEvent (59179070). If the queue size further increases above the incremental value and the time period has been exceeded then another instance of the alarm OV_PMDAppQEvent will be issued containing the updated queued value. This mechanism continues until either the application empties the queue, or is terminated.

The following steps will configure the option:

1. cd $OV_LRF (Unix)

cd %OV_LRF% (Windows)

2. Edit the file pmd.lrf and add the option. The following sets a threshold of 1000 events, an incremental value of 250 with a 5 minute time period.

pmd:pmd:

OVs_YES_START::-SOV_EVENT;J"QEvent%1000@250@300":OVs_WELL_BEHAVED:30:PAUSE

3. ovaddobj pmd.lrf

4. Finally pmd needs to be restarted:

ovstop -c

ovstart -c

An example of the default message over a number of measured time periods:

Firstly, the initial 1000 alarm threshold is breached:

"1226404936 6 Tue Nov 11 17:32:16 2008 <nnmserver> P Queue size of Application ovactiond pid 21567 has crossed the threshold 1000. The current queue size is 1001;1 17.1.0.59179070 0"

After 300 seconds, if a further 250 events (the incremental value) have been queued, a second alarm is logged:

"1226404936 6 Tue Nov 11 17:32:16 2008 <nnmserver> P Queue size of Application ovactiond pid 21567 has crossed the threshold 1250. The current queue size is 1255;1 17.1.0.59179070 0"

A further 300 seconds later, if a further 250 alarms have been queued, a third alarm is logged:

"1226404936 6 Tue Nov 11 17:32:16 2008 <nnmserver> P Queue size of Application ovactiond pid 21567 has crossed the threshold 1500. The current queue size is 1541;1 17.1.0.59179070 0"

Note:

It is not possible to enable this option using the pmdmgr interface. It can only be configured via the pmd.lrf file.

To combine multiple "J" options then should be seperated using the ^ (carat) character.

For example:

J"QEvent%1000@250@300^enableAppDisconnect^logStats%600@1000"

KM544676 New logStats J option in ov_event IP22

A new "J" option for pmd's "OV_EVENT" stack has been introduced in NNM 7.53 patch IP22.

The new "J" option (logStats) allows pmd to be configured to regularly log messages to the pmd.log0 file indicating the event in/out rate and the size of the attached applications event queues. Queued events can cause pmd to grow in memory size and can indicate a hung application, while high values for the event rate can overload pmd's processing capabilities.

The new option can be configured with a time period and an event count using the following format:

J"logStats%<timePeriod>@<eventCount>"

The log messages are written to the file every <timePeriod> seconds, or when the number of events received has increased by <eventCount> events.

The following steps will configure the option:

1. cd $OV_LRF (Unix)

cd %OV_LRF% ( Windows)

2. Edit the file pmd.lrf and add the option. The following sets a time period of 10 minutes and an event count of 1000 events.

pmd:pmd:

OVs_YES_START::-SOV_EVENT;J"logStats%600@1000":OVs_WELL_BEHAVED:30:PAUSE

3. ovaddobj pmd.lrf

4. Finally pmd needs to be restarted:

ovstop -c

ovstart -c

An example of the log message is:

Event in rate: 0.8, Event out rate: 0.5, List of EventQueue: "ovtrapd(438)": 0, "ovactiond(439)": 0, "ovtopmd(437)": 0, "ovalarmsrv(440)":0, "snmpCollect(448)": 0, "netmon(447)": 0

The numbers in the braces are the application Process ID (Pid). The values after the ":" indicate the number of events waiting to be sent to the application.