logo
Manual Pages
Table of Contents

NAME

na_ems - Invoke commands to the ONTAP Event Management System

SYNOPSIS

ems [ event | log ] status ems log dump value

DESCRIPTION

The Event Management System (EMS) collects event data from various parts of the ONTAP kernel and provides a set of filtering and event forwarding mechanisms. EMS views three distinct entities: 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_fault
A temporary loss of service has been detected, typically a transient software fault.
node_error A hardware error has been detected which is not immediately fatal. svc_error A software error has been detected which is not immediately fatal.
warning
A high-priority message, does not indicate a fault.
notice
A normal-priority message, does not indicate a fault.
info
A low-priority message, does not indicate a fault.
debug
A debugging message, typically suppressed.

OPTIONS

log dump value
Dump the contents of the log over a period of time. The value argument is specified as a time quantity of hours [nh] or days [nd]. log status
Return the status of the EMS log. event status
Return the status describing events that have been processed by the EMS engine. status Return a terse version of the EMS engine status.

LOG FILE INFORMATION

EMS supports a built-in logging facility that logs all EMS events. The log is kept in /etc/log/ems, and is rotated weekly. 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=""> <cf_fsm_stateTransit_1
oldState="UP"
newState="TAKEOVER"
elem="S100_18 (Noop)"/> </LR> 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.

STATUS

The ems command can be used to return status of the EMS log and EMS event processing facility. 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 fields have the following meanings: Event:Priority
The name of the event followed by its priority. Last Time
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. Indications
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. DupSuppr
The number of times an event indication of this type was suppressed by duplicate suppression. TimerSuppr
The number of times an event indication of this type was suppressed by timer suppression. AutoSuppr
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
The first field indicates the name of the log (LOG_default). The remaining fields have the following meanings:
save
The number of rotated files that are saved.
rotate The file rotation policy. size The amount of data written to the currently active log file.
file
The name of the log file.
format The encoding format of the log file. level The priority level filtering. indications
Number of event indications received. drops The number of events that were dropped due to resource constraints. last update
The time at which the last event indication was processed. Remaining fields contain data associated with the last event indication.

REGISTRY USAGE

EMS uses the system registry to store its persistent configuration. All of the EMS configuration variables are collected under the options.ems branch of the registry.

CLUSTER CONSIDERATIONS

EMS supports per-node configurations in a cluster environment. However, events that are specific to the system configuration of the surviving node in a takeover are sent only to the EMS consumers for that node.

SEE ALSO

na_snmp(1), na_snmpd(8), na_syslog.conf(5), na_syslogd(8)

BUGS

Support for configurable EMS forwarding of SNMP, autosupport, and syslog is not contained in this release.
Table of Contents