Logging
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.
You can modify the SR Linux logging configuration using the CLI, northbound API, or by editing the .conf files manually. The SR Linux device overwrites 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.
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.
Linux syslog facilities describes the Linux syslog facilities that can be used as input sources for log messages.
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 |
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 |
SR Linux logging subsystem names 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.
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 |
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.
Logging priorities describes the logging priorities in order of severity.
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 |
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:
Send the messages to a specified file in the /var/log/srlinux/file/ directory.
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.
Send the messages to the console; that is, the Linux device
/dev/console
, which may be assigned to a serial device in hardware.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.
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:
-
Specific text within a message
-
Prefix text at the beginning of a message
-
Linux facility that generated the message
-
Regular expression matching text within the message
-
Syslog tag of the message
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 Logging priorities for a list of logging priorities.
--{ * candidate shared default }--[ ]--
# info system logging
system {
logging {
filter f1 {
facility kern {
priority {
match-above warning [
}
}
}
}
}
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 default }--[ ]--
# info system logging
system {
logging {
filter f2 {
contains accounting {
facility local6 {
priority {
match-above informational [
}
}
}
}
}
Logging destination configuration
You can configure the SR Linux to send logging information to the following destinations:
- A log file
- Memory buffer storage
- The console (
/dev/console
) - One or more remote servers
Specifying a log file destination
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).
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 default }--[ ]--
# info system logging
system {
logging {
file cron-critical {
facility cron {
priority {
match-exact [
critical
]
}
}
}
}
}
The following example sends messages matching criteria specified in filter f1 to the file /var/log/srlinux/file/f1-match:
--{ * candidate shared default }--[ ]--
# info system logging
system {
logging {
file f1-match {
filter [
f1
]
}
}
}
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 default }--[ ]--
# info system logging
system {
logging {
file aaa-warn-info {
subsystem aaa {
priority {
match-exact [
warning
informational
]
}
}
}
}
}
Specifying a buffer destination
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.
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 default }--[ ]--
# info system logging
system {
logging {
buffer f1-match {
rotate 5
size 5000000
filter [
f1
]
}
}
}
Specifying the console as destination
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.
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 default }--[ ]--
# info system logging
system {
logging {
console {
subsystem accounting {
priority {
match-above informational
}
}
}
}
}
Specifying a remote server destination
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.
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 default }--[ ]--
# info system logging
system {
logging {
network-instance mgmt
remote-server 1.1.2.2 {
subsystem bgp {
priority {
match-above alert
}
}
}
}
}
}
Specifying a Linux syslog facility for SR Linux subsystem messages
All of the messages generated by SR Linux subsystems (see SR Linux logging subsystem names) 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 Linux syslog facilities for the syslog facilities.
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 default }--[ ]--
# info system logging
system {
logging {
subsystem-facility local7
}
}