Technical Documentation
Overview of System Logging
System events are classified into event categories. Using the CLI, you can determine which event categories to log. To fully utilize the logging facility, you need to understand log severity and log verbosity.
Log Severity
Log severity is a level that is assigned to an event or log message. Log severity levels apply to event categories, such as bulkStats, bgpRoutes, or atm1483.
The minimum severity of a log message for an individual category is described either by a severity number in the range 0–7 or a descriptive priority term, such as emergency or debug. The lower the severity number is, the higher the priority. See Table 1.
 | Note: Not every event category supports every severity level. For a list of event categories and the severity levels that each category supports, see Unresolved xref. |
Table 1: Log Severity Descriptions
Severity Number | Severity Name | System Response |
|---|---|---|
0 | Emergency | System unusable; shelf reset |
1 | Alert | Immediate action needed; card reset |
2 | Critical | Critical conditions exist; interface is down |
3 | Error | Error conditions; nonrecoverable software error |
4 | Warning | Warning conditions; recoverable software error |
5 | Notice | Normal but significant conditions; nonerror, low-verbosity information |
6 | Info | Informational messages; nonerror, medium-verbosity information |
7 | Debug | Debug messages; nonerror, high-verbosity information |
Log Verbosity
The verbosity level determines the amount of information that appears in each message. You can assign the verbosity level for the log category. Verbosity levels can be any of the following:
- Low—Terse
- Medium—Moderate
- High—Verbose
Note: Many event categories provide only low-verbosity detail regardless of the verbosity setting.
Persistent Logs
Log messages can survive a system reboot. After a reboot, the system rebuilds the list of log messages. However, if the system detects any problems or has gone through a power cycle, the buffer is reset, and the log messages from the previous session are lost.
Log messages are not synchronized between primary and redundant SRP modules. During a switchover from a primary to a redundant SRP module, existing log messages are not transferred to the redundant SRP module.
