Syslog-Severities
In the example log entries in Table 37. Syslog severities, the prefixes are removed. For example. this is a complete log entry with the prefix:
2020 Apr 12 11:20:27.612 : 17U-18U : PSERV : MERG : !!! hsl Module crashed, System reboot halted as it rebooted continuosly 2 timesThis is the same log entry without the prefix:
hsl Module crashed,System reboot halted as it rebooted continuosly 2 times|
Severity Level |
Keyword |
Description |
|
0 |
emergency |
The whole system is unusable and needs operator intervention to recover. If only a particular port or component is unusable, but the system as a whole is still usable it is not categorized at an emergency level. Examples of this type of message: Output Power of PSU XX (psu_no) XX Watt] has exceeded Maximum Output Power Limit[XX Watt] OSPF Initialization failed. |
|
1 |
alert |
The operator needs to act immediately or the system might go into emergency state. The system or one of its component's functionality might be critically affected. Examples of this type of message: Temperature of sensor is (curr_temp)C. It is nearing Emergency Condition. OSPF has exceed lsdb limit OSPF Detected router with duplicate router ID [ID] |
|
2 |
critical |
A critical system event happened which requires the operator's attention. The event might not require immediate action, but this event can affect functionality or behavior of a system component. Examples of this type of message: OSPF Neighbor session went down. Interface %s changed state to down |
|
3 |
error |
An error event happened which does not require immediate attention. This log message provides details about error conditions in the system or its components which you can use to troubleshoot problems. These events are not logged directly even if the logging level is set to include this level. You also need to enable the protocol debug filters (such as Examples of this type of message: Device i2c bus open error.!!! [DECODE] Attr ASPATH: Invalid AS Path value. OSPF MD5 authentication error |
|
4 |
notification |
Notifications about important system and protocol events to assure the operator that the system is running properly. If a critical/alert condition has happened and has been corrected, that is also logged at this level. Examples of this type of message: OSPF Received link up for interface: xe1 OSPF neighbour [10.1.1.1] Status change Exstart -> Exchange Interface %s changed state to UP |
|
5 |
informational |
Detailed informational events happening across the system and protocol modules. These events are not necessarily important and are useful only to find details about the functionality being executed in the system and its components. Some of these events might be periodic events like hello or keep alive messages along with packet dumps. Also, this level includes logs for control packets that are ignored and do not impact the protocol states. IP Infusion Inc. recommends to use proper debug filters to log only relevant events and switch off other events; otherwise the logs can get verbose. For example: debug ospf all no debug ospf packet hello The above enables all OSPF debugging, but disables the periodic hello messages. Examples of this type of message: Successfully added dynamic neighbour [DECODE] KAlive: Received! [FSM] Ignoring Unsupported event <EVENT> in state <STATE> Unknown ICMP OSPF RECV[%s]: From %r via %s: Version number mismatch OSPF RECV[%s]: From %r via %s: Network address mismatch |
|
6 |
debug informational |
Developer notification events that might not be readable by an operator. However these logs are useful for debugging by a developer and if required, this level needs to be enabled and provided to technical support for analysis. |
|
7 |
debug detailed |
Developer notification events that might not be readable by an operator. However these logs are useful for debugging by a developer and if required, this level needs to be enabled and provided to technical support for analysis. |
Log File Rotation
| • | Log rotation is important to maintain the stability of the device, because the larger log files are difficult to manipulate and file system would run out of space. The solution to this common problem is log file rotation. |
| • | Log rotation is scheduled to happen for every 5 minutes, here the log file size is used as the condition to perform rotation. |
| • | Log rotate operation creates a backup of the current log file, and clears the current log file content. Also these rotated log files are compressed to save disk space. Excluding the current log file, four backup files are maintained in the system, and the older logs are removed as part of the rotation operation. |
| • | Default log file /var/log/messages rotated, if the size is greater than 100 MB. The following are the rotated log files generated in the path /var/log. |
root@host:/var/log# ls messages*
messages messages.1 messages.2.gz messages.3.gz messages.4.gz| • | Manually configured log file /log/LOG1 gets rotated, if its size is greater than configured size. Here LOG1 is the manually configured using the command logging logfile <filename> and the log file size in bytes can be configured using the command logging logfile LOG1 <severity> size <4096-419430400> |
(config)#logging logfile LOG1 7 size 4096| • | Here configured logging file /log/LOG1 is rotated if the size is greater than 4096 bytes. The following are the rotated log files generated in the path /log |
root@host:/log# ls LOG*
LOG1 LOG1.1 LOG1.2.gz LOG1.3.gz LOG1.4.gz