Description

This article describes the Junos OS syslog severity levels and the associated numerical values, which can be used to interpret system logs correctly. The article also shares a few syslog configuration guidelines.

Solution

Syslog records messages according to "facility" and "severity". By default, messages logged in the standard Junos OS format do not include information related to facility and priority. As an option, when the "explicit-priority" statement is included, the Junos OS logging utility prepends codes for the facility name and severity level to the message that are directed to remote hosts or Routing Engines.

[edit]
usr@MX# set system syslog file messages
<facility> <severity> ;
explicit-priority;

[edit]
usr@MX# set system syslog file messages <facility> ? 

Possible completions:
    alert             Conditions that should be corrected immediately
    any               All levels
    critical          Critical conditions
    emergency         Panic conditions
    error             Error conditions
    info              Informational messages
    none              No messages
    notice            Conditions that should be handled specially
    warning           Warning messages

Example 1 - Without "explicit-priority" configured

Sep 29 17:37:54 MX mgd[68339]: UI_CMDLINE_READ_LINE: User 'root', command 'exit '
Sep 29 17:37:54 MX mgd[68339]: UI_DBASE_LOGOUT_EVENT: User 'root' exiting configuration mode
Sep 29 17:37:58 MX mgd[68339]: UI_CMDLINE_READ_LINE: User 'root', command 'show log messages '

Example 2 - With "explicit-priority" configured

Sep 29 17:35:12 MX mgd[68339]: %INTERACT-6-UI_CMDLINE_READ_LINE: User 'root', command 'exit '
Sep 29 17:35:12 MX mgd[68339]: %INTERACT-5-UI_DBASE_LOGOUT_EVENT: User 'root' exiting configuration mode
Sep 29 17:35:16 MX mgd[68339]: %INTERACT-6-UI_CMDLINE_READ_LINE: User 'root', command 'show log messages'

As shown in Example 2 above, the syslog messages with "explicit-priority" indicates the logging-level (considered as priority) as well as the facility of each message logged, and may help determine the degree of verbosity to settle for (any, info, notice etc...).
The FreeBSD syslog service defines the severity and its numerical values shown as below table. The Junos OS logs syslog message whose priority is equal and higher than the configured numerical value: (eg. If the severity level "warning(4)" is set, syslog message whose severity levels of emergency(0), alert(1), critical(2), error(3), and warning(4) are logged.). There are two exceptions to this rule. No messages are logged by setting "none", and all severity levels are logged by setting "any".

+-----------+-------+----------------------------------+
| Severity  | Level | Definition                       |
+-----------+-------+----------------------------------+
| EMERGENCY |   0   | system is unusable               |<---- Highest priority
+-----------+-------+----------------------------------+
| ALERT     |   1   | action must be taken immediately |
+-----------+-------+----------------------------------+
| CRITICAL  |   2   | critical conditions              |
+-----------+-------+----------------------------------+
| ERROR     |   3   | error conditions                 |
+-----------+-------+----------------------------------+
| WARNING   |   4   | warning conditions               |
+-----------+-------+----------------------------------+
| NOTICE    |   5   | normal but significant condition |
+-----------+-------+----------------------------------+
| INFO      |   6   | informational                    |
+-----------+-------+----------------------------------+
| DEBUG     |   7   | debug-level messages             |<---- Lowest priority
+-----------+-------+----------------------------------+

General Guidelines
In general, these syslog severity levels should be configured based on the customer's operation policy. Usually, in production, "any warning(4)" or "any notice(5)" could be considered as good practice.
Syslog configured with "any any” might provide more information. But it also increases the burden on writing tasks into local storage (Harddisk, Flashdisk). Over a longer period, it might not be effective to have too much messages which is not considered worthwhile. For such large amounts of messages, remote syslog-servers can be a better option with better understanding on the limitation that some messages may be lost due to local buffer overflow or syslog packet lost (as syslog run on UDP) when there is bursty "any any" messages.
Syslog configured with "any any" running for a certain period of time can be helpful for the purpose of investigation, troubleshooting, etc.
 

Modification History

2026-01-08: Minor, non-technical changes made

2020-July-30: Article reviewed for accuracy; no changes required. 

Related Information