O'Reilly logo

Event Management and Best Practices by Michael Wallace, Guilherme Pereira, Jacqueline Meckwood, Peter Glasmacher, Tony Bhe

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 6. Event management products and best practices 297
that time interval is reached, it is reset and starts when the next matched event is
received.
6.6.3 Multiple IBM Tivoli Enterprise Console servers
This section lists a few examples of when event synchronization is needed
between IBM Tivoli Enterprise Console event server.
CLOSED event synchronization from a low-level IBM Tivoli
Enterprise Console event server
One example of event synchronization between IBM Tivoli Enterprise Console
servers is when you close an event at a lower level IBM Tivoli Enterprise Console
event server. Automatic event synchronization is required to escalate this
situation to the upper level IBM Tivoli Enterprise Console event server.
Synchronizing events between IBM Tivoli Enterprise Console servers can
sometimes be a challenging task. You must make sure that, whenever you close
an event on one server, that event is closed on all servers. This helps to avoid
errors when correlating this event on all levels of your IBM Tivoli Enterprise
Console servers.
IBM Tivoli Enterprise Console 3.9 comes with an out-of-the box rule that helps
you forward an event from one IBM Tivoli Enterprise Console event server to
another. This rule is called
forwarding.rls and is not activated by default. A little
customization of this rule is necessary for true bi-directional synchronization
between your IBM Tivoli Enterprise Console servers. You also need to tell this
rule what kind of events you want to forward.
You may be dealing with a hierarchy of IBM Tivoli Enterprise Console servers. In
this case, a low-level IBM Tivoli Enterprise Console event server does most of
your correlating. Then any duplicate detection and filtering that are not caught at
the gateway are forwarded along with any remaining events to a high-level IBM
Tivoli Enterprise Console event server. This high-level IBM Tivoli Enterprise
Console event server is responsible for correlating all events from all sources.
Figure 6-38 shows the relationship between the event sources and the different
levels of IBM Tivoli Enterprise Console servers. The lines that connect the two
IBM Tivoli Enterprise Console servers, NetView and the trouble-ticketing system,
are bidirectional.
298 Event Management and Best Practices
Figure 6-38 Relationship between IBM Tivoli Enterprise Console servers in a hierarchy
Now let’s look at the forwarding.rls rule. The default action part of the
forwarding.rls rule does not provide any rules that synchronize a closed event
with other IBM Tivoli Enterprise Console servers. For our purposes, we modify
this rule so that events are also forwarded to the other IBM Tivoli Enterprise
Console servers when an event is closed.
Example 6-34 shows the first part of the forwarding.rls rule. This is the reception
action section of the forwarding_configure rule.
Example 6-34 Reception action of the forwarding.rls rule
create_event_criteria(ups_fatal_forwarding, % event criteria name
'upsDischarged', % class to filter on
yes, % fire on non-leaf only (yes/no)
[ ['severity', within, ['FATAL'] ] % criteria based on slots
]
Tier 1
Entry Tier
Tier 2
Event Sources
Trouble Ticketing
System
High Level TEC Server
Lower Level TEC server
NetView
Chapter 6. Event management products and best practices 299
),
create_event_criteria(temp_alarm_forwarding, % event criteria name
'chassisAlarmOffTempAlarm',% class to filter on
yes, % fire on non-leaf only (yes/no)
[ ['severity', within, ['WARNING','FATAL'] ] % criteria based
on slots
]
),
This is the section of this rule where you define the type of events to forward. You
must also set the event server to where you will forward these events in the
tec_forward.conf file that is located in the TEC_RULES directory. See 6.4.3,
“Rules” on page 251, for more information about how you can place this
information into a fact file.
There are two examples or forwarding rules by default: one for
ups_fatal_forwarding and one for create_event_criteria. We use a test event
class for our testing. We modify this section of the rule as outlined in
Example 6-35.
Example 6-35 Test event class within the forwarding.rls rule
create_event_criteria(test_tec_event_forwarding,
'TEC_Test_Event',
yes,
[ ['severity', within, ['WARNING','FATAL'] ]
]
),
We use the TEC_Test_Event class for this example. We forward only it if the
severity is WARNING or FATAL. Example 6-36 shows the section of the rule
where the actual forwarding takes place.
Example 6-36 Forwarding section of the forwarding.rls rule
rule: forwarding_events:
(
event: _event of_class _class
where [
],
reception_action: forward_event:
(

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required