Users Guide

System events and alarms
An event noties you of a change or situation in the system that you might be interested in. An alarm indicates that the system has entered
an abnormal state and may require immediate action.
Events are classied into:
• Stateless events—One-time notications about the system condition, for example, ACL updates, rewall policy update, and so on.
• Stateful events—Events that are raised when the abnormal situation arises, and cleared when the situation returns to normal. These
types of events are called alarms.
Events can have one of the following severities:
• CRITICAL—A critical condition exists and requires immediate action. A critical event may trigger if one or more hardware components
fail, or one or more hardware components exceed temperature thresholds.
• MAJOR—A major error had occurred and requires escalation or notication. For example, a major alarm may trigger if an interface
failure occurs, such as a port channel being down.
• MINOR—A minor error or noncritical condition occurred that, if left unchecked, might cause system service interruption or
performance degradation. A minor alarm requires monitoring or maintenance.
• WARNING—A warning condition was observed, but it may or may not result in an error condition.
• INFORMATIONAL—An informational event had occurred, but it does not impact performance.
Out of memory, temperature crossing a critical point, and so on, are examples of conditions when the system triggers an alarm. After the
system recovers from the condition, the alarms are cleared.
All stateful events of severity level CRITICAL, MAJOR, MINOR, or WARNING trigger alarms. However, you can customize the severity of
events or turn o event notication using Severity proles.
Triggered alarms are in one of these states:
• Active—Alarm is raised and is currently active.
• Acknowledged—Alarm is raised; the user is aware of the situation and acknowledged the alarm. This alarm does not impact the overall
health of the system or the system LED.
Some alarms go directly from active to cleared state and require little-to-no administrative eort. You must acknowledge or investigate
alarms with a high severity.
OS10 stores all Active and Acknowledged alarms in the Current Alarm List (CAL), and archives all past events in the Event History List
(EHL).
Alarms in the CAL are cleared after a reload.
The EHL is persistent and retains the archived events after a reload, reboot, or upgrade. The EHL can store a maximum of 86,000 events or
30 days of events, whichever is earlier.
The system LED that indicates the status of the switch is based on the severity of the alarms in the CAL and it turns:
• Red—For CRITICAL or MAJOR alarms
• Amber—For MINOR or WARNING alarms
• Green—No alarms
1352
Troubleshoot OS10