This section describes the different types of monitors that are available, and how to define your own monitors using the OVO administrator’s GUI.
Overview of OVO Monitoring Capabilities
OVO enables the monitoring of numeric values that are determined either by:
❏ Program
Calling a program at regular intervals that submits a numeric value to OVO.
❏ External Program
Accepting numeric values that are determined by some external mechanism and passed to OVO. These values can be accepted at any time.
❏ MIB variables
Polling MIB variables at regular time intervals.
The primary mechanism for monitoring numeric values in OVO is threshold monitoring. Threshold monitors can be set up to use any of the above methods to determine new values. Threshold monitors can, therefore, be used to poll MIB variables and to monitor any other values.
Threshold monitors are designed to watch numeric values which might indicate problems, and to generate messages as soon as a potential problem is detected. It is, however, important to avoid overwhelming operators by generating many redundant messages. To prevent such a flood of redundant messages, OVO threshold monitors enable redundant messages to be filtered out, for example, by defining time intervals after which a new message may be generated. As with other OVO message sources, the full set of action options (automatic and operator-initiated actions, automatic acknowledgment, etc.) can be configured for the messages generated by a threshold monitor, together with instructions, external notification, and trouble ticket services. Threshold monitors do not, by default, store the data that has been collected.
Event Integration Through Messages
A second mechanism, specifically for polling MIB variables and referred to as MIB Data Collection, is also provided by OVO. In contrast to threshold monitors, this mechanism can be configured to store the collected data which can be used to analyze trends in monitored variables by plotting the values against time. This type of monitor also supports threshold values but does not provide their sophisticated filtering capabilities. Events can also be generated based on exceeded thresholds and on returning to “normal” values, but it is not
straightforward to set up an action to resolving a problem.
Monitoring MIB Variables
When deciding whether to use a threshold monitor or MIB data collection, consider the following points:
❏ To collect and store data for the later plotting of graphs, it is recommended to use MIB data collection.
❏ To generate a message as soon as a monitored value indicates a problem, it is recommended to use threshold monitoring.
❏ If the OVO management server is at a location remote from the objects for which MIB variables are monitored, and if network load and management server workload are issues, threshold monitoring might be more suitable for the following reasons:
• With MIB data collection, the OVO management server polls the managed objects at regular intervals with a request for data and receives a response.
• With threshold monitoring, the OVO intelligent agent polls the monitored object. If the object is a node running the OVO agent, additional network traffic, due to MIB variable polling, is not generated. The only additional network traffic is caused when a
Event Integration Through Messages
• Even if the object for which a MIB variable is monitored is not running an OVO intelligent agent, the threshold monitor can still reduce the network load. In this case, it is recommended to use an intelligent agent running on a machine located close to the monitored object. Additional network load caused by MIB variable polling is, therefore, restricted to a small part of the network. This reduces the overall network load and the workload of the management server. If the OVO management server is connected to the managed objects over a WAN, this situation can be especially beneficial in terms of network load.
Figure 3-7 Comparison of Network Traffic Caused Monitoring Methods
MIB Data Collection:
Considerable additional network traffic caused between the OVO management server and the object for which the MIB variable is monitored
Threshold Monitoring:
Considerable additional network traffic caused only between the object to be monitored and a nearby agent OVO
Event Integration Through Messages
Using Threshold Monitoring to Generate Messages
You can configure OVO to monitor managed nodes at regular time intervals, during which the monitored value is calculated and compared against a threshold value. If the threshold is exceeded, whether a message is generated depends on the type of monitor selected and on the
“history” of values relative to the reset value.
If a message is generated, you can set message attributes and custom message attributes, and provide instructions, annotations, and actions, in the same way as for any other message generated by matching a message condition. When a message is generated and all message attributes are set, it is sent to the management server. If a local automatic action has been defined, this is also started in parallel. Note that only when the threshold is exceeded does OVO monitoring cause network traffic.
The threshold monitoring scripts, provided by the user, are invoked by the monitoring agent in the configured time interval, except for values monitored externally. The monitor agent checks the success of the scripts by interpreting the exit value. If the exit value is not equal to 0, indicating script failure, the monitor agent sends an appropriate message to the Message Agent that forwards the message to the management server.
The script collects one or more current values of the objects to be monitored and sends them to the monitor agent through a C library routine or a command interface provided by OVO, with a call to opcmon(1|3). See the man pages opcmon(1) and opcmon(3) for more information.
The check of externally monitored objects is not invoked by the monitor agent, however, it checks whether a value from an object has arrived through a call toopcmon(1|3) at least every 15 seconds.
Event Integration Through Messages
The monitor agent checks the received values against the configured thresholds and creates user-defined messages for any exceeded threshold values. This happens for the values of all types of objects (program, external or SNMP MIB) that arrive at the monitor agent. If the monitor agent receives a value of an object which was not configured, it will generate an opcerror log entry with an appropriate warning on the managed node. For example:
File is:/var/opt/OV/log/OpC/<managed_node>/opcerror OVO message: OpC30-613
08/05/00 10:39 WARNING Monitor Agent(10827):
Can’t find object ‘<Monitored Object>’.
Unknown monitor ’<Monitored Object>’.
Ignoring received value.
If a monitored object should be checked by a user-provided script invoked by the monitor agent, and a corresponding name-value pair is not returned, (that is, the script/program does not callopcmon) the monitor agent will generate a warning message and send it to the management server. For example, the message OpC30-608:
Can’t retrieve value for monitor <Monitored Object>.
Suppressing further error messages.
Event Integration Through Messages
Message Generation Policies and Message Filtering
Threshold monitoring enables you to choose either a minimum or maximum threshold:
❏ Maximum threshold monitoring
As long as the values received from the monitored object are less than the threshold value, no messages are generated. If the values reach or exceed the threshold value, then OVO generates the configured message for this object.
❏ Minimum threshold monitoring
As long as the actual values received from the monitored object are above the threshold value, no messages are generated. If they reach or drop below the threshold value, then OVO generates the
configured message for this object. The generation of further
messages depends on how the message generation type is configured, see below.
To prevent redundant messages from cluttering the operators’ Message Browsers, OVO provides three mechanisms you can use to generate further messages after the value of a monitored object crosses a defined threshold:
❏ Message generation on crossing threshold with Reset If the monitored value reaches or crosses the threshold, OVO
generates one message. Before OVO generates further messages, the monitored value must either:
• Drop below the reset value for maximum threshold monitoring, or
• Rise above the reset value for minimum threshold monitoring.
Event Integration Through Messages
❏ Message generation continuously
OVO generates a message each time the monitored value is either:
• equal to or greater than the threshold for maximum threshold monitoring, or
• equal to or less than the threshold for minimum threshold monitoring.
The frequency of the message generation in this case depends on the configured polling interval.
It is also possible to specify that a message is only to be generated when the monitored value exceeds the threshold for a longer duration than a defined period. You can do this by setting theDurationparameter in the Add/Modify Threshold Monitor window.
Event Integration Through Messages
Figure 3-8 Message Generation Policies For Maximum Thresholds