6. Logging

6.1. Overview

The SR Linux device implements logging via the standard Linux syslog libraries. The SR Linux device uses rsyslog in the underlying Linux OS to filter logs and pass them on to remote servers or other specified destinations.

The main configuration file for rsyslog is /etc/rsyslog.conf. The SR Linux installs a minimal version of the /etc/rsyslog.conf file, and maintains an SR Linux-specific configuration file in the /etc/rsyslog.d/ directory. Per-application logging configuration files are also kept in the /etc/rsyslog.d/ directory; these files are named /etc/rsyslog.d/<nn>-<app>.conf.

The SR Linux logging configuration can be modified using the CLI, northbound API, or by editing the .conf files manually. The SR Linux device will overwrite any parts of the configuration that are owned by SR Linux, and this may supersede any configuration done manually.

The SR Linux .conf files in /etc/rsyslog.d use standard rsyslog syntax for configuring filters and actions within rules.

The SR Linux supports configuration of Linux facilities and SR Linux subsystems as sources for log messages to filter. See the SR Linux Log Events Guide for properties and descriptions of the log messages that can be generated by SR Linux subsystems.

Basic logging configuration consists of specifying a source for input log messages, filtering the log messages, and specifying an output destination for the filtered log messages.

6.1.1. Input sources for log messages

The SR Linux supports using messages logged to Linux syslog facilities and messages generated by SR Linux subsystems as input sources for log messages.

Table 6 describes the Linux syslog facilities that can be used as input sources for log messages.

Table 6:  Linux syslog facilities  

Facility

Description

auth

Security/authorization messages that do not contain secret information

authpriv

Security/authorization messages that may contain secret information

cron

Messages generated by cron

daemon

Messages generated by system daemons without their own facility

ftp

Messages generated by an FTP daemon

kern

Messages generated by the kernel

local0

Local use 0

local1

Local use 1

local2

Local use 2

local3

Local use 3

local4

Local use 4

local5

Local use 5

local6

Local use 6

local7

Local use 7

lpr

Messages generated by the line printer subsystem

mail

Messages generated by a mail client or server

news

Messages generated by the network news subsystem

syslog

Messages generated internally by syslog

user

Messages generated by a user

uucp

Messages generated by the UUCP (unix-to-unix copy) subsystem

Table 7 lists the SR Linux subsystems that produce messages that can serve as input sources for log messages. By default, SR Linux subsystem messages are logged to Linux syslog facility local6.

Table 7:  SR Linux logging subsystem names  

Subsystem

Description

aaa

Messages generated by the aaa_mgr application (not including accounting messages)

accounting

Accounting messages generated by the aaa_mgr application

acl

Messages generated through an ACL log action

app

Messages generated by the aaa_mgr application

arpnd

Messages generated by the arp_nd_mgr application

bfd

Messages generated by the bfd_mgr application

bgp

Messages generated by the bgp_mgr application

chassis

Messages generated by the chassis_mgr application

fib

Messages generated by the fib_mgr application

gnmi

Messages generated by the gnmi_server application

json

Messages generated by the json_rpc_server application

linux

Messages generated by the linux_mgr application

lldp

Messages generated by the lldp_mgr application

mgmt

Messages generated by the mgmt_svr application

mpls

Messages generated by the mpls_mgr application

netinst

Messages generated by the net_inst_mgr application

policy

Messages generated by the policy_mgr application

sdk

Messages generated by the sdk_mgr application

staticroute

Messages generated by the static_route_mgr application

xdp

Messages generated by the xdp_mgr application

6.1.2. Filters for log messages

You can configure filters to target specific messages or groups of log messages captured within the input message source.

A filter can specify the set of messages generated by a Linux facility at a specified priority; for example, messages generated by the kernel that have a priority of warning or higher, or mail facility messages that have a priority of critical.

Filtering can be done for messages generated by a specific SR Linux subsystem; for example, messages generated by the aaa_mgr application, or messages generated by the chassis_mgr application. SR Linux subsystem messages go to a specified Linux facility (by default, local6), and you can create filters for subsystem-specific messages from this facility.

Table 8 describes the logging priorities in order of severity.

Table 8:  Logging priorities  

Code

Priority name

Description

0

emergency

System is unusable

1

alert

Action must be taken immediately

2

critical

Critical conditions

3

error

Error conditions

4

warning

Warning conditions

5

notice

Normal but significant conditions

6

informational

Informational messages

7

debug

Debug-level messages

6.1.3. Output destinations for log messages

You can set the action that the SR Linux takes for input messages that meet the criteria specified in a filter. This can include sending the messages to a destination such as a log file, the console, or a remote host.

For example, you can configure the SR Linux to send messages generated by the kernel that have priority warning to a file called /var/log/srlinux/file/kernel-warning.

Messages generated by an SR Linux subsystem, such as the bgp_mgr or gnmi_server application, can be sent to specified destinations.

Actions for messages matching a filter can include the following:

  1. Send the messages to a specified file in the /var/log/srlinux/file/ directory.
  2. Send the messages to a buffer. A buffer is similar to a file, but uses memory as storage and is not persistent across system reboots. Messages sent to a buffer are stored in the /var/log/srlinux/buffer/ directory.
  3. Send the messages to the console; that is, the Linux device /dev/console, which may be assigned to a serial device in hardware.
  4. Send the messages to one or more remote servers. You can specify a network-instance where rsyslogd is run and which serves as the source for the messages.

6.2. Defining filters

Filters target specific messages or groups of log messages within the input message source. Filter criteria for log messages can include the following:

  1. Specific text within a message
  2. Prefix text at the beginning of a message
  3. Linux facility that generated the message
  4. Regular expression matching text within the message
  5. Syslog tag of the message

Example:

The following example shows a configuration that creates a filter that matches messages from the Linux facility kern that have a priority of warning or higher. See Table 8 for a list of logging priorities.

--{ * candidate shared }--[  ]--
# info system logging
 system {
     logging {
         filter f1 {
                facility kern {
                    priority {
                        match-above warning [
                    }
                }
         }
     }
 }

Example:

The following example creates a filter that matches messages from the Linux facility local6 (where SR Linux subsystem messages are logged by default) that have a priority of informational or higher and contain the text accounting. This filter can be used to match messages from the SR Linux accounting subsystem.

--{ * candidate shared }--[  ]--
# info system logging
 system {
     logging {
         filter f2 {
                contains accounting {
                facility local6 {
                    priority {
                        match-above informational [
                    }
                }
         }
     }
 }

6.3. Specifying logging destinations

6.3.1. Specifying a log file

The SR Linux can send log messages to a specified log file. By default, the log file resides in the /var/log/srlinux/file directory. You can specify the retention policy for the file, including the maximum size (default 10 MB), as well as the number of files to keep in the rotation (default 4 files).

Example:

The following example uses messages from Linux facility cron as input, filters the messages for those that have critical priority, and sends the filtered messages to the file /var/log/srlinux/file/cron-critical:

--{ * candidate shared }--[  ]--
# info system logging
 system {
     logging {
         file cron-critical {
                facility cron {
                    priority {
                        match-exact [
                            critical
                        ]
                    }
                }
         }
     }
 }

Example:

The following example sends messages matching criteria specified in filter f1 to the file /var/log/srlinux/file/f1-match:

--{ * candidate shared }--[  ]--
# info system logging
 system {
     logging {
         file f1-match {
                filter [
                    f1
                ]
         }
     }
 }

Example:

The following example uses messages generated by the SR Linux AAA subsystem (that is, messages generated by the aaa_mgr application, but not including accounting messages) as input. The messages are filtered for those that have warning or informational priority, and the filtered messages are sent to the file /var/log/srlinux/file/aaa-warn-info.

--{ * candidate shared }--[  ]--
# info system logging
 system {
     logging {
         file aaa-warn-info {
                subsystem aaa {
                    priority {
                        match-exact [
                            warning
                            informational
                        ]
                    }
                }
         }
     }
 }

6.3.2. Specifying a buffer

The SR Linux can send log messages to a buffer. A buffer is similar to a file, except that a buffer uses memory as storage and is not persistent across system reboots.

When the SR Linux device boots, it creates a non-swappable tmpfs virtual filesystem at /var/log/srlinux/buffer. This tmpfs filesystem has a fixed size of 512 MB, which is reserved for buffer usage.

When a buffer is created through a commit transaction, the SR Linux verifies that there is enough buffer space available to contain all configured buffers based on their retention policies. If sufficient space is not available, the commit transaction fails.

Example:

The following example sends messages matching criteria specified in filter f1 to the buffer /var/log/srlinux/buffer/f1-match. A retention policy is specified so that when the buffer reaches 5,000,000 bytes, messages are written to a new buffer. After five buffers are filled, the oldest one is overwritten.

--{ * candidate shared }--[  ]--
# info system logging
 system {
     logging {
         buffer f1-match {
                rotate 5
                size 5000000
                filter [
                    f1
                ]
         }
     }
 }

6.3.3. Specifying the console

You can specify the console as a destination for log messages. The console refers to Linux device /dev/console, The console may be assigned to a serial device in hardware.

Example:

The following example uses messages generated by the SR Linux accounting subsystem as input, filters the messages for those that have informational priority or higher, and sends the filtered messages to /dev/console:

--{ * candidate shared }--[  ]--
# info system logging
 system {
     logging {
         console {
                subsystem accounting {
                    priority {
                        match-above informational
                    }
                }
         }
     }
 }

6.3.4. Specifying a remote server

The SR Linux can send log messages to one or more remote servers. You can specify the network-instance that the SR Linux uses to contact the remote servers. The rsyslogd process is run within the specified network-instance.

Example:

The following example uses messages generated by the SR Linux BGP subsystem (that is, messages generated by the bgp_mgr application) as input, filters the messages for those that have alert priority or higher, and sends the filtered messages to a remote server. The messages are sourced from the mgmt network-instance.

--{ * candidate shared }--[  ]--
# info system logging
 system {
     logging {
         network-instance mgmt
         remote-server 1.1.2.2 {
                subsystem bgp {
                    priority {
                        match-above alert
                    }
                }
            }
        }
    }
 }

6.4. Specifying a Linux syslog facility for SR Linux subsystem messages

All of the messages generated by SR Linux subsystems (see Table 7) are logged to the same Linux syslog facility. This allows you to filter messages from all SR Linux subsystems by capturing logs from this facility.

By default, SR Linux subsystem messages are logged to the Linux syslog facility local6. You can optionally specify a different syslog facility. See Table 6 for the syslog facilities.

Example:

The following example changes the Linux syslog facility where messages generated by SR Linux subsystems are logged from the default of local6 to local7:

--{ * candidate shared }--[  ]--
# info system logging
 system {
     logging {
         subsystem-facility local7
     }
 }