OVNM 5.3 - Operations Agent for NonStop Object Configuration Client Guide

Object Configuration Client: The Understanding 51
EMS Burst Suppression Considerations
The following methods can be used to suppress duplicate EMS messages from being processed and/or sent to
Enterprise Managers.
1. Collector Level Burst Suppression
The first method involves suppressing the duplicate EMS messages at the collector level. You will need to
use EMSCCTRL to configure this option. This method eliminates the workload from OVNM to implement
burst suppression. Refer to the appropriate HP documentation for more details.
2. EMS Distributor Level Burst Suppression
The second method involves suppression at the EMS Distributors that are used by OVNM. This method also
eliminates the workload from OVNM to implement burst suppression. Refer to the appropriate HP
documentation for details.
3. Object Configuration Client Level Burst Suppression
The Object Configuration Client can be used to define the EMS burst definitions for each EMS threshold
where burst suppression should be used. Burst suppression requires an EMS threshold to be defined .
When you create an EMS threshold, you specify the SSID, Event number and any other attributes that
describe the event(s) you want captured. The Object Configuration Client allows you to use wildcards in
various portions of the threshold definition. For example, you can create an EMS Threshold for the SSID
TANDEM.PATHWAY and all events (*). You can specify that the event text needs to contain a particular
string. All of these attributes are used to determine whether or not the EMS message should be processed
by OVNM, and what actions should be performed. You can configure it to send an email, or perform an
automated action (user-defined command). You can also use the EMS threshold definition to define how
you want the message sent to HP operations Manager/Console or any other enterprise management
system (using the eEvents panel).
When OVNM is deciding whether or not an EMS message should be considered part of a burst, it will
always compare the SSID and EVENT – regardless of how the EMS threshold was defined. So, for a given
EMS threshold, there could be several “threads” of burst definitions. For example – if you define an EMS
threshold for SSID TANDEM.PATHWAY and the event number you specify is an asterisk (all events), then
each unique event number that Pathway generates will be treated as a separate burst thread. So Pathway
could generate 100 events and still not cause a ‘burst’, if each event has a unique event number. Burst
criteria can also use the SUBJECT of the event. In the Object Configuration Client, if you enter a specific
value in the Event Subject field in the eBurst panel, then only events with that subject will be considered
when ‘counting’ EMS messages (regardless of how the EMS threshold was defined). If you leave the Event
Subject blank, then subject will NOT be used when counting events – in other words, only the SSID and
Event Number will be used when counting events. In that scenario, ten events with different subjects will all
be counted in the same bucket (or burst thread). If you enter an asterisk into the Event Subject field in the
eBurst panel, then each unique subject will be treated independently. So if we use the
TANDEM.PATHWAY example again, and you are capturing TCP down events, then a given TCP will have
to generate enough of the down events for OVNM to consider it a burst. If you have 100 TCP’s and they
all go down, this would not be considered a burst since each subject would be different. If you want it to
be considered a burst, then leave Event Subject blank.
When deciding whether or not you should define the Event Subject in the eBurst panel, keep in mind how
your EMS threshold was defined. If you used the EVENT SUBJECT or EVENT SUBJECT MANAGER
condition when defining the threshold, then you may not need to specify anything in the eBurst panel for
Event Subject since the threshold criteria is already limiting which subjects are processed.
Since a given EMS threshold could have several or even hundreds of separate burst threads, you might
have to adjust some parameters. These parameters need to be defined between the CUSTOMER
CHANGES #1 lines in the OCCCONF and OVNMCONF files. Burst definitions are used by BOTH halves
of the OVNM application – the recovery/email portion (ACC) and the Enterprise/Console portion
(EMON).
THREADTABLECOUNT is used to define the number of entries to be used in the burst thread table. The
default value is 100. This means that OVNM will support up to 100 individual/concurrent burst threads at
a time. If you need more than that, you will need to add a SET statement to the OCCCONF/OVNMCONF
files. If this value is too small, OVNM will generate Event 142 “Burst Thread Table is full. Increase
THREADTABLECOUNT.” After you increase the value, you will need to bounce OVNM for the change to
take effect.