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 debug ospf all). 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 packet type" 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. |