Event Management and Best Practices

32 Event Management and Best Practices

processed are input via ASCII files. They can come from a wide variety of

sources such as Microsoft Windows® Event Logs, IBM Tivoli Enterprise

Console wtdumprl output, and log files.

The events are parsed to determine event type and relevant information within

the event. The various analysis functions of the tool, including reporting event

frequency by type and host, event rates by time-of-day, and statistical

correlation of events, can use the event details. There are also predictive

functions within the tool that enable the practitioner to see the impact of

implementing various filtering and correlation rules for the given list of events.

2.2 Policies and standards

Critical to the success of event management is the process of creating event

processing policies and procedures and tracking compliance with them. Without

this, an organization lacks consistency and accountability. When different support

groups implement their own event management, the tools used are not

configured to standards, making them difficult to configure and maintain.

Inconsistent tool use can affect measurements, such as mean-time to repair,

make accountability more difficult, or skew the problem counts that may be used

to determine staffing in the various support groups.

Each event handling action—filtering, forwarding, duplicate detection, correlation,

escalation, synchronization, notification, trouble ticketing, and

automation—should be described in a documented policy. This makes it easier to

make event processing decisions and implement systems management tools.

In this section, we discuss important policies and procedures to develop and

document in addition to those that specifically describe the major event handling

actions of filtering, duplicate detection, correlation, escalation, and automation.

For each, we recommend that you list the policy and its implications.

Note that some implications always follow from the policy, and others depend

upon your systems management toolset or organizational structure. Table 2-1

shows an example in which the implications always follow from the policy.