OVNM 5.3 - Operations Agent for NonStop Object Reference Guide

Threshold Policies 29
Policy
Description
Operators Allowed
XPNET MESSAGES QUEUED
This threshold type allows the user to check the total
number of messag
es queued by the XPNET process
for all stations, processes, links and queue
processes. The Valid values are 0 - 268427263.
• Equal to <value1>
• Not equal to <value1>
• Less than <value1>
• Less than or equal to <value1>
• Greater than <value1>
• Greater than or equal to <value1>
• Greater than <value1> and less
than <value2>
• Less than <value1> or greater than
<value2>
XPNET PROCESSES STARTED
COUNT
This threshold type allows the user to check the
number of XPNET processes in the STARTED state.
The valid values are 0-4096.
• Equal to <value1>
• Not equal to <value1>
• Less than <value1>
• Less than or equal to <value1>
• Greater than <value1>
• Greater than or equal to <value1>
• Greater than <value1> and less
than <value2>
• Less than <value1> or greater than
<value2>
XPNET STATIONS STARTED
COUNT
This threshold type allows the user to check the
number of XPNET stations in the STARTED state.
The valid values are 0-4096.
• Equal to <value1>
• Not equal to <value1>
• Less than <value1>
• Less than or equal to <value1>
• Greater than <value1>
• Greater than or equal to <value1>
• Greater than <value1> and less
than <value2>
• Less than <value1> or greater than
<value2>
NOTE:
OVNM supports two different methods of monitoring BASE24 objects. The first is the ability to specify
certain thresholds for lines, stations, links, processes and resource nodes (systems). These thresholds are
monitored using a SPI interface with the Base24 NCP process(s). It supports multiple BASE24 systems on a
single node as well as BASE24 User
ID security if the STATUS or INFO commands are protected. The impact
on the system is dependent on the number of objects being monitored and the polling interval. Detection of
problems is currently restricted to the polling interval, the longer the polling
interval; the longer a failure might
go unnoticed.
The second option is to use the EMS thresholds. O
VNM can intercept any EMS message, from any application
including BASE24 or HP NonStop subsystem and take action based on what is contained within that EMS
event.
The impact on the system is based on the filter that is used to provide EMS messages to $OVOCC.
$OVOCC
uses its own forwarding distributor. To make it easy for customers, the default filter will be one that
passes all events to
$OVOCC. However, customers can write their own filter and use that instead of our
default filter. That way, if they were only interested in BASE24 messages, they could limit the amount of
processing
$OVOCC performs by using a filter that only passed OVNM events and BASE24 events. There are
no buffer files for processing EMS events and they are processed in real time.
O
VNM supports a combination of both of those types of monitoring. For many systems, version 4.0 onwards
will correlate EMS messages with standard thresholds. For example,
if OVNM is configured to monitor for
Pathway TCP failures, as soon as the EMS message is generated stating that a TCP has failed,
OVNM will
recognize it and report it as a violation. This will allow polling intervals to be set rather high since they will
only be needed when an EMS message is missed.
In addition, the thresholds that start with ATM are driven entirely by EMS events
– no polling is used. When
specific EMS events are detected, the Object State is changed accordingly.