EMS Manual

Reporting Events
EMS Manual—426909-005
8-2
Task 1: Decide What Events to Report
Task 1: Decide What Events to Report
Determine what events your subsystem can detect, which of those events it should
report to EMS, and which of those reported events should be considered critical or
action events.
Task 1.1: Decide Which Detectable Events to Report to EMS
In general, your subsystem should produce an event message to report any
occurrence that might affect how the system or network is managed or maintained. Be
selective, however, to avoid overwhelming management applications and operations
staff with messages that are of little help to them.
These guidelines can help you decide what to report for your subsystem:

Report any significant unexpected occurrence, such as data loss or hardware or
software failure.

Report occurrences necessary for diagnosing a problem, such as state changes,
path switches, and takeovers by backup processes, even if expected. For example,
problem diagnosis applications might rely entirely on the event message log, and
an unreported path switch could cause confusion.

Report an action-attention event whenever your subsystem is unable to continue
without operator intervention. When the operator has taken the appropriate action
or the problem is otherwise cleared, report an action-completion event to indicate
that operator intervention is no longer required.

Report events only about the objects closely related to your subsystem. Your event
message might mention an object controlled by another subsystem if that object
had a supporting role in the event, but the object in your subsystem should be the
principal subject of the event message. For example, if your subsystem cannot
access a file because a disk volume is unavailable, your subsystem should report
its own problem (inability to access a file) and assume that the disk process will
report (or already has reported) any exceptional conditions relating to the disk
volume.

Report events of interest to multiple people or applications. Do not report events
when the audience is limited and identifiable. For example, if a user supplies a file
name and the file is not present, report the error to the user, but do not send an
event message to EMS.

Report events that result from an analysis of statistics (such as an error rate
exceeding an established threshold value), but do not create an event message
just to report statistics. The preferred way to provide access to statistics is to
support a command message (such as STATS) that returns statistics in its
response.

Report each significant occurrence of an event, but not each event when a flurry of
similar events occur because of the same basic problem (if your subsystem can