232 Event Management and Best Practices
򐂰 itmquery --server nodeA --dump-endpoints
--dump-products-for-endpoints false
Lists the endpoints for IBM Tivoli Monitoring server nodeA.
򐂰 itmquery --dump-endpoints
Lists the endpoints for all IBM Tivoli Monitoring servers configured in the
/usr/OV/conf/itm_servers.conf file. For each endpoint, the recognized
products are also listed. You can configure which products are recognized by
changing the /usr/OV/conf/itm_attributes.conf file.
򐂰 itmquery --dump-endpoints --dump-products-for-endpoints false
Lists the endpoints for all IBM Tivoli Monitoring servers configured in the
/usr/OV/conf/itm_servers.conf file.
6.3.2 IBM Tivoli Enterprise Console correlation
IBM Tivoli Enterprise Console has many ways to perform correlation. In this
section, our goal is to list those methods, along with reasons behind them.
State correlation engine
The newest form of correlation available within IBM Tivoli Enterprise Console 3.9
is the state correlation engine, available on IBM Tivoli Enterprise Console
gateways. This feature is not enabled by default, and must be configured for use.
The rules for this engine are developed via XML and not the common Prolog
format used with the normal IBM Tivoli Enterprise Console event server rule
bases. You can develop these rules from a central location (Tivoli Management
Region (TMR) server) and distribute them to the appropriate gateways via
MDIST.
For information about configuring an IBM Tivoli Enterprise Console gateway to
enable state correlation, follow the steps outlined in the IBM Tivoli Enterprise
Console User’s Guide, Version 3.9, SC32-1235.
For correlation purposes, we discuss two of the six rule types available with the
state correlation engine: pass-through and reset on match.
Pass-through rules
The pass-through rule forwards the trigger event only if a specific set of events
arrives within a specified time interval. If the required events arrive before the
timer expires (optionally is a specific sequence), the trigger event is forwarded. If
they do not arrive, the timer resets and the trigger event is not forwarded.
Chapter 6. Event management products and best practices 233
Reset on match rules
The reset on match rule forwards the trigger event only if a specific set of events
does not arrive within a specified time interval. If the required events arrive before
the timer expires (optionally a specific sequence), the trigger event is not
forwarded. If they don’t arrive, the timer resets and the trigger event is forwarded.
A situation that can be used as an example of this predicate is for NetView event
Node Down. This is not a trusted event since it can be generated by a problem
with the NetView polling to the node and it can still be alive. To be more sure that
IBM Tivoli Enterprise Console receives only an event if the node is really down, a
state correlation rule using the predicate reset on match can be used.
In Example 6-14, a rule was created to identify Node Down events and wait six
minutes (this time was defined because the default polling interval for NetView is
five minutes) after it arrives. If no Node Up event arrives in this time, the Node
Down event is sent. If it was a polling error or time out and the next polling
succeeds, no event is generated.
Example 6-14 Code for reset on match rule
<rule id="nodeDown.resetOnMatchOfUp">
<eventType>TEC_ITS_NODE_STATUS</eventType>
<resetOnMatch timeInterval="360000" randomOrder="false">
<cloneable ignoreMissingAttributes="false" attributeSet="hostname"/>
<predicate>
<![CDATA[
&source == "nvserverd" &&
&nodestatus == "DOWN"
]]>
</predicate>
<predicate>
<![CDATA[
&source == "nvserverd" &&
&nodestatus == "UP"
]]>
</predicate>
</resetOnMatch>
</rule>
Note: The best practice to address this situation is to create a rule directly on
NetView. However, if you can’t or it requires too much work, the IBM Tivoli
Enterprise Console gateway is the next step.
234 Event Management and Best Practices
The first test made with this rule was to unplug the network cable for node
PHIWAS01, in our lab environment, for more than six minutes. Figure 6-14
shows that the Node Down event was received six minutes after the Interface
Down event for that node. Then, the reset on match predicate for state correlation
creates a time window that matches the first criteria. In the defined time window,
if no event is received in matching the second criteria, then the event is sent. The
interface down event for that node was not filtered to easily present the case.
Figure 6-14 IBM Tivoli Enterprise Console Event Viewer Node Down
When the Node Up event arrives after the time window expires, it goes to the
event server that correlates it and closes the Node Down event (Figure 6-15).
Figure 6-15 IBM Tivoli Enterprise Console Event Viewer Node Up

Get Event Management and Best Practices now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.