 |
» |
|
|
|
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 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
