 |
» |
|
|
|
When designing an application
or a subsystem, you must also design an associated set of events. EVM events must be designed with care. Events must meet the requirements
of two format types: the human style (readable text) and the program
style (binary data). After an event is posted, it can be viewed
in text form, and an appropriate action can be taken. Consider the following guidelines while designing an event: Decide on a family name for a set of
related events. For more information, see “Event Name Data Item” Create a list of status changes that may be of interest
to a monitoring entity, and choose a name for each event. For more
information about monitoring entity, see “Deciding Which Status Changes are Eventworthy”. Decide on the contents of each event. Each individual
event must have a unique name. Most events need a format string
and a priority, and many events need variables. For each variable,
consider the type and possible values. For more information about
EVM event content, see “EVM Event Content”. Write a detailed description of each event for documentation purpose,
and include information about the following: Any actions the user or responsible subscriber must
take in response to the event, and The contents of the event (particularly any variable
data items)
The explanation text is usually captured in a catalog file
and can be accessed for display. For more information about explanation
text, see “Writing Event Explanation Text”. For each event, decide the data items that go into
the template and the data items that are coded by the poster. Except
for the event name, all items in both posting code and templates
are optional. If an optional data item is declared in both places,
the poster's declaration has precedence. For information about templates,
see “Designing Event Templates”.
For information about event items that are commonly posted, see “EVM Event Content”. For information
about how data items in templates and posted events are merged,
see “Merging Data Items from Templates and Posted Events”. Decide whether the events must be internationalized.
If so, choose a name for the I18N catalog file and establish any
required message sets within the catalog. For information about
internationalization of events, see “Establishing Translations for Event Text
(I18N)”.
Designers must recognize that an EVM event is an interface on
which other programs or subsystems may rely on. Therefore, once
established, the interface must not be changed. Deciding Which Status Changes are Eventworthy | |
The importance of an event can vary from application to application,
and it may be difficult in some cases to decide whether a status
change recognized by your code is important enough to communicate
to others. EVM recommends that you post events for the following types
of occurrences: When a component makes
a change to the system. For example, a System Management program can
post an event if it adds a new user to the system, or changes the
network configuration. When a potentially significant error occurs. For
example, a System Management program must post an event if it finds
that a key system file is missing, and a Device driver must post
an event if it detects a disk failure. When a threshold limit is
reached and a failure is likely to occur. For example, File System
Management software may post a warning event when it detects that
a file system has reached a threshold limit, and has become at least
95 percent full. However, you must avoid posting repeated events
of this nature if the state oscillates around the threshold limit.
Your code must typically post the same event again if the condition
is still true after some preset time interval has elapsed; even
if the state has dropped below the threshold limit and recovered
several times within the time interval. When a user is granted a privilege or takes some
action that affects the operation of the system. For example, a
System Management program may post an event when a disk is mounted
or unmounted, or when the system is closing down.
Do not post events for the following types of occurrences: In response to an error made by a user in a session
that is under your control, and where you have direct communication
with the user. For example, a configuration program must not post
an event because a user responded incorrectly to a prompt. If you are dealing with an “error” that
meets the following criteria: the error is expected and is normal
behavior, you know why the error is displayed, and the error does
not cause a system administrator to take any action. If the condition that you have just detected was
reported very recently, and reporting it again serves no useful
purpose.
You must avoid posting the same event repeatedly over a short
period of time. For example, if there is a condition oscillating
between true and false, do not repeat the event posting for this
condition. In some cases, it may be helpful to post an occasional
summary event, stating that the same incident occurred multiple
times within a specified length of time. High levels of event activity can cause the loss of events
because an application may not be able to handle the message load. For
information on how to handle missed events, see “Dealing with Missed
Events”. Writing Event Explanation Text | |
You must supply explanation text for every EVM event. Explanation
text is not included within an event when it is posted, but can
be included in a catalog file and referenced by the contents of
the event's reference and name data items. For more information
about data items, see “Reference Data Item”. The explanation text for sys.unix events
is physically held in a catalog file named evmexp.cat.
To display the explanation text for an event, use the -x or
-d option of evmshow. Your explanation must include the name of the event and a
description of what it means. If an event conveys different aspects
depending on the context (for example, the number of occurrences
within a given time period, or the presence of certain other events),
then state that fact and provide a couple of sample situations.
Whenever an action is required, state the action to be taken. If
the action varies with the context, then state that fact and provide
examples. If the event does not require an action from the user, state explicitly that
the action is not required. Example 2-1 “ Sample Event Explanation Text” shows
sample explanation text for a system event. Example 2-1 Sample Event Explanation Text EVENT sys.unix.evm.daemon.event_activity
Explanation:
This high-priority event is posted by the EVM daemon when it
detects a high number of events occurring over several minutes.
Action: Use the evmget(1) command to review the event log for the source of the activity. If the log does not show high activity around the time at which this event was posted, it is likely that the events were low priority, and hence were not logged. You can monitor low-priority events by running the evmwatch(1) command with an appropriate filter, or by temporarily reconfiguring the EVM logger to log low-priority events.
Note: You can change the parameters that control the posting
of this event by modifying the daemon configuration file,
/etc/evmdaemon.conf. |
|
Printable version
