Table of Contents
ems log dump value
An event producer recognizes the existence of an event and generates an event indication.
An event consumer describes events that it wants to receive based on filtering information within the event indication (type of message, contents within message).
The EMS engine receives indications from event producers and forwards to event consumers based on filtering descriptions.
EMS supports the following event consumers:
The logging consumer receives events from the engine and writes out event indication descriptions using a generic text-based log format.
The syslog consumer receives events from the engine and forwards to the kernel syslog facility.
The SNMP trap consumer receives events from the engine and forwards to the kernel SNMP trap genera_tor.
An EMS event has a name, typically expressed in a dotnotation format, and a collection of named attributes. Attribute values are either strings or integers. An EMS event has a priority associated with it. The following priority levels are defined:
node_fault A data corruption has been detected or the node is unable to provide client service.
svc_error A software error has been detected which is not immediately fatal.
Return the status of the EMS log.
Return the status describing events that have been processed by the EMS engine.
status Return a terse version of the EMS engine status.
Rotated log files are identified by an integer suffix. For example, the first rotated file would normally be /etc/log/ems.0, the second /etc/log/ems.1, and so on.
The log file format is based on Extensible Markup Language (XML) fragments and contains information describing all of the data associated with the event indication. The following is an example log record associated with an event describing a state transition in the cluster monitor:
<LR d="28Nov2005 16:24:59" n="toaster1" t="1133195099" id="1133194781/198" p="4" s="OK" o="fm_main" vf="">
Events are identified by a type described as an XML element (cf_fsm_stateTransit_1), version, date (d), node name (n), system time (t), generation and sequence (id), priority (p), status (s), owning ONTAP process (o) and vFiler name (o). The remaining information is associated with an event of this particular type: the old and new states of the cluster monitor (oldState, newState), and an internal identifier for the state transition (elem).
The format of the EMS log file is subject to change in a future release.
To get event processing information, the ems event status command is issued. Here is an example of its output:
Current time: 27Jan2006 15:21:36 Engine status: indications 20, drops 0, suppr (dup 0, timer 0, auto 0) Event:Priority Last Time Indications Drops DupSuppr TimerSuppr AutoSuppr ems.engine.endReplay:INFO 27Jan2006 15:21:25 1 0 0 0 0 ems.engine.startReplay:INFO 27Jan2006 15:21:25 1 0 0 0 0 kern.rc.msg:NOTICE 27Jan2006 15:21:26 2 0 0 0 0 kern.syslog.msg:console_login:INFO 27Jan2006 15:21:31 1 0 0 0 0 kern.syslog.msg:httpd:WARN 27Jan2006 15:21:26 1 0 0 0 0 kern.syslog.msg:init:WARN 27Jan2006 15:21:24 1 0 0 0 0 kern.syslog.msg:main:DEBUG boot 0 0 0 0 0 kern.syslog.msg:rc:DEBUG 27Jan2006 15:21:29 2 0 0 0 0 kern.syslog.msg:rc:NOTICE 27Jan2006 15:21:24 1 0 0 0 0 raid.vol.state.online:NOTICE 27Jan2006 15:21:29 1 0 0 0 0 wafl.vol.loading:DEBUG 27Jan2006 15:21:20 2 0 0 0 0
The name of the event followed by its priority.
This field contains timestamp header information associated with the last event received of this type. A value of local indicates that the event was received by EMS on behalf of the local node. A value of partner indicates that the event was received by EMS on behalf of a cluster partner node.
The number of event indications of this type that have been received.
Drops The number of times an event indication of this type was dropped due to resource constraints.
The number of times an event indication of this type was suppressed by duplicate suppression.
The number of times an event indication of this type was suppressed by timer suppression.
The number of times an event indication of this type was suppressed by auto suppression.
To get log status, the ems log status command is issued. Here is an example of its output:
EMS log data: [LOG_default] save 5, rotate weekly, size 26155 file /etc/log/ems, format xml level debug indications 73, drops 0 last update: 27Jan2006 15:25:25
size The amount of data written to the currently active log file.
level The priority level filtering.
Number of event indications received.
drops The number of events that were dropped due to resource constraints.
The time at which the last event indication was processed.
Remaining fields contain data associated with the last event indication.
Table of Contents