Information About Embedded Event Manager
The ability to detect and handle critical events in the Cisco NX-OS system is important for high availability. The Embedded Event Manager (EEM) provides a central, policy-driven framework to detect and handle events in the system by monitoring events that occur on your device and taking action to recover or troubleshoot these events, based on your configuration..
EEM consists of three major components:
- Event statements
-
Events to monitor from another Cisco NX-OS component that may require some action, workaround, or notification.
- Action statements
-
An action that EEM can take, such as sending an e-mail or disabling an interface, to recover from an event.
- Policies
-
An event paired with one or more actions to troubleshoot or recover from the event.
Without EEM, each individual component is responsible for detecting and handling its own events. For example, if a port flaps frequently, the policy of "putting it into errDisable state" is built into ETHPM.
Embedded Event Manager Policies
An EEM policy consists of an event statement and one or more action statements. The event statement defines the event to look for as well as the filtering characteristics for the event. The action statement defines the action EEM takes when the event occurs.
For example, you can configure an EEM policy to identify when a card is removed from the device and log the details related to the card removal. By setting up an event statement that tells the system to look for all instances of card removal and an then with an action statement that tells the system to log the details.
You can configure EEM policies using the command line interface (CLI) or a VSH script.
EEM gives you a device-wide view of policy management. Once EEM policies are configured, the corresponding actions are triggered. All actions (system or user-configured) for triggered events are tracked and maintained by the system.
Preconfigured System Policies
Cisco NX-OS has a number of preconfigured system policies. These system policies define many common events and actions for the device. System policy names begin with two underscore characters (__).
Some system policies can be overridden. In these cases, you can configure overrides for either the event or the action. The overrides that you configure take the place of the system policy.
Note |
Override policies must include an event statement. Override policies without event statements override all possible events for the system policy. |
To view the preconfigured system polices and determine which polices you can override, use the show event manager system-policy command.
User-Created Policies
User-created policies allow you to customize EEM policies for your network. If a user policy is created for an event, actions in the policy are triggered only after EEM triggers the system policy actions related to the same event.
Log Files
The log file that contains data that is related to EEM policy matches is maintained in the event_archive_1 log file located in the /log/event_archive_1 directory.
Event Statements
Any device activity for which some action, such as a workaround or notification, is taken is considered an event by EEM. In many cases, events are related to faults in the device, such as when an interface or a fan malfunctions.
Event statements specify which event or events triggers a policy to run.
Tip |
You can configure EEM to trigger an EEM policy that is based on a combination of events by creating and differentiating multiple EEM events in the policy and then defining a combination of events to trigger a custom action. |
EEM defines event filters so that only critical events or multiple occurrences of an event within a specified time period trigger an associated action.
Some commands or internal events trigger other commands internally. These commands are not visible, but will still match the event specification that triggers an action. You cannot prevent these commands from triggering an action, but you can check which event triggered an action.
Supported Events
EEM supports the following events in event statements:
-
Counter events
-
Fan absent events
-
Fan bad events
-
Memory thresholds events
-
Events being used in overridden system policies.
-
SNMP notification events
-
Syslog events
-
System manager events
-
Temperature events
-
Track events
Action Statements
Action statements describe the action that is triggered by a policy when an event occurs. Each policy can have multiple action statements. If no action is associated with a policy, EEM still observes events but takes no actions.
In order for triggered events to process default actions, you must configure the EEM policy to allow the default action. For example, if you match a CLI command in a match statement, you must add the event-default action statement to the EEM policy or EEM does not allow the command to execute.
Note |
When configuring action statements within your user policy or overriding policy, it is important that you confirm that action statements do not negate each other or adversely affect the associated system policy. |
Supported Actions
EEM supports the following actions in action statements:
-
Execute any CLI commands
-
Update a counter
-
Reload the device
-
Generate a syslog message
-
Generate an SNMP notification
-
Use the default action for the system policy
VSH Script Policies
You can write policies in a VSH script, by using a text editor. Policies that are written using a VSH script have an event statement and action statement(s) just as other policies, and these policies can either augment or override system policies.
After you define your VSH script policy, copy it to the device and activate it.
Licensing Requirements for Embedded Event Manager
This feature does not require a license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide.
Prerequisites for Embedded Event Manager
You must have network-admin privileges to configure EEM.
Guidelines and Limitations for Embedded Event Manager
When you plan your EEM configuration, consider the following:
-
The maximum number of configurable EEM policies is 500.
-
Action statements within your user policy or overriding policy should not negate each other or adversely affect the associated system policy.
-
To allow a triggered event to process any default actions, you must configure the EEM policy to allow the default action. For example, if you match a command in a match statement, you must add the event-default action statement to the EEM policy or EEM does not allow the command to execute.
-
The following guidelines apply to Event Log Auto-Collection and Backup:
-
By default, enabled log collection on a switch provides between 15 minutes to several hours of event logs depending on size, scale and component activity.
-
To be able to collect relevant logs that span a longer period, only enable event log retention for the specific services/features you need. See "Enabling Extended Log File Retention For a Single Service". You can also export the internal event logs. See "External Log File Storage".
-
When troubleshooting, it is good practice to manually collect a snapshot of internal event logs in real time. See "Generating a Local Copy of Recent Log Files".
-
-
An override policy that consists of an event statement and no action statement triggers no action and no notification of failures.
-
An override policy without an event statement overrides all possible events in the system policy.
-
In regular command expressions: all keywords must be expanded, and only the asterisk (*) symbol can be used for replace the arguments.
-
EEM event correlation supports up to four event statements in a single policy. The event types can be the same or different, but only these event types are supported: cli, counter, snmp, syslog, and track.
-
When more than one event statement is included in an EEM policy, each event statement must have a tag keyword with a unique tag argument.
-
EEM event correlation does not override the system default policies.
-
Default action execution is not supported for policies that are configured with tagged events.
-
If your event specification matches a CLI pattern, you can use SSH-style wild card characters.
For example, if you want to match all show commands, enter the show * command. Entering the show . * command does not work.
-
If your event specification is a regular expression for a matching syslog message, you can use a proper regular expression.
For example, if you want to detect ADMIN_DOWN events on any port where a syslog is generated, use .ADMIN_DOWN. . Entering the ADMIN_DOWN command does not work.
-
In the event specification for a syslog, the regex does not match any syslog message that is generated as an action of an EEM policy.
-
If an EEM event matches a show command in the CLI and you want the output for that show command to display on the screen (and to not be blocked by the EEM policy), you must specify the event-default command for the first action for the EEM policy.
Default Settings for Embedded Event Manager
Parameters | Default |
---|---|
System Policies | Active |