Logging
SR Linux implements logging via the standard Linux rsyslogd package. With dynamic configuration, log filters can be defined and passed to remote servers or other specified destinations.
SR Linux
log_mgr application supports the standard RFC 5424 message format when
relaying syslog messages to remote servers.
RFC 5424 introduces a more structured and extensible syslog message format designed to overcome the limitations of the earlier syslog formats, such as RFC 3164. RFC 5424 includes features like high-precision time-stamping with timezone information and support for embedding structured log data.
The main configuration file for rsyslogd is /etc/rsyslog.conf. SR Linux installs a minimal version of the /etc/rsyslog.conf file and maintains an SR Linux-specific configuration under the /etc/rsyslog.d/ directory.
You can configure SR Linux logging using the CLI or a northbound API. Although you can add *.conf files manually in the /etc/rsyslog.d directory, it is not recommended.
SR Linux .conf files under /etc/rsyslog.d use standard rsyslog syntax for configuring filters and actions within rules.
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.
Logging configuration consists of specifying a source for input log messages, possibly filtering messages by some pattern, and specifying an output destination.
Templates are easy-to-reuse message formats. rsyslog contains pre-defined templates
identified by the RSYSLOG_ prefix.
For
information about the supported rsyslog templates, see sections Rsyslog templates for local buffer, file, or console output and Rsyslog templates for forwarding messages to remote servers.
Input sources for log messages
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 |
|---|---|
|
all |
All supported Linux syslog facilities |
|
audit |
Audit messages |
|
auth |
Security/authorization messages that do not contain secret information |
|
authpriv |
Security/authorization messages that may contain secret information |
|
console |
Alert messages |
|
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 |
|
ntp |
Messages generated by NTP subsystem |
|
syslog |
Messages generated internally by syslog |
|
user |
Messages generated by a user |
|
uucp |
Messages generated by the UUCP (UNIX-to-UNIX copy) subsystem |
See the Log Events Guide for more information about SR Linux logging subsystem names.
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 action 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 grpc_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.
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 include or exclude specific prefix, text within a
message, or regular expressions. Negative matching uses the if not
condition from rsyslog, which allows you to exclude specific log messages.
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 performed 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 it is 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 |
Defining filters
Filters target specific messages or groups of log messages in the input message source. You can define the following filter criteria for log messages:
-
specific text in a message
-
prefix text at the beginning of a message
-
Linux facility that generated the message
-
regular expression matching text in the message
-
syslog tag of the message
-
subsystem of the message
-
remove specific messages from being logged using the following filter criteria that have negative matches:
-
does not contain specific text in a message
-
does not contain specific prefix text at the beginning of a message
-
does not contain specific regular expression matching text in the message
-
Match kernel messages with warning or higher priority
The following example shows a configuration that creates a filter that matches messages from the Linux facility kernel that have a priority of warning or higher. See Logging priorities for a list of logging priorities.
--{ + candidate shared default }--[ ]--
# info with-context system logging filter f1
system {
logging {
filter f1 {
facility kern {
priority {
match-above warning
}
}
}
}
}
Match informational or higher accounting messages
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 with-context system logging filter f2
system {
logging {
filter f2 {
contains accounting
facility local6 {
priority {
match-above informational
}
}
}
}
}
Exclude informational or higher accounting messages
The following example creates a filter that excludes 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.
--{ + candidate shared default }--[ ]--
# info with-context system logging filter f3
system {
logging {
filter f3 {
not-contains accounting
facility local6 {
priority {
match-above informational
}
}
}
}
}
Logging de-duplication
Setting
facility local6 and facility auth results in
messages from local6 or auth to be matched.
A configuration that is defined to include contains
username and prefix
host1 results in matching messages that have
username and a prefix of host1. A
configuration that is defined to include contains
interface and not-contains
down results in matching messages that include
interface and not down.
The composition-operator allows the two options [
AND | OR ], where the default is
OR. This field is used to define additional matching
criteria.
Output filters, facility, and subsystems logic
When a filter has a composition-operator set to
OR, the filter is considered a logical OR for
inclusion in the output.
For example, an output that includes filter 1
(composition-operator set to OR) and
subsystem chassis includes all messages from filter
1 and all messages from the chassis subsystem.
When a filter has a composition-operator set to
AND, the filter is considered a logical AND
for inclusion in the output.
For example, an output that includes filter 2
(composition-operator set to AND),
subsystem chassis, and facility local6
includes messages that are in both filter 2 and the chassis
subsystem, and in both filter 2 and local6.
Message duplication handling
A message in an output stream only appears one time, even if it matches multiple filters, facilities, or subsystems. When a match occurs when evaluating a message for an output, no further evaluation is required. If a message is matched by any filter, facility, or subsystem for an output, the message is sent and further processing is stopped.
Filter simple match
The following example creates the filter hostnameMatch that finds messages from facility local6 that contain hostname.
This configuration also creates the output buffer log, which uses the filter.
Messages that are matched must be from the source local6 and contain the word hostname.
--{ * candidate shared default }--[ ]--
# info with-context system logging
system {
logging {
filter hostnameMatch {
contains hostname
facility local6 {
}
}
buffer log {
filter [
hostnameMatch
]
}
}
}
Filter dual sources
The following example creates the filter hostnameMatchDualFacility that finds messages from facility local6 and facility local5 that contain hostname.
This configuration also creates the output buffer log, which uses the filter.
Messages that are matched must be from the source (local6 or local5) and contain the word hostname.
--{ * candidate shared default }--[ ]--
# info with-context system logging
system {
logging {
filter hostnameMatchDualFacility {
contains hostname
facility local5 {
}
facility local6 {
}
}
buffer log {
filter [
hostnameMatchDualFacility
]
}
}
}
Filter facility and subsystem
The following example creates the filter hostnameMatchFacilitySubsystem that finds messages from facility local6 and subsystem acl that contain the word hostname.
This configuration also creates the output buffer log, which uses the filter.
Messages that are matched must be from the source (local6 or acl) and contain the word hostname.
--{ * candidate shared default }--[ ]--
# info with-context system logging
system {
logging {
filter hostnameMatchFacilitySubsystem {
contains hostname
facility local6 {
}
subsystem acl {
}
}
buffer log {
filter [
hostnameMatchFacilitySubsystem
]
}
}
}
Request dual filters
The following example creates the filter hostnameMatch that finds messages from facility local6 that contain the word hostname. This configuration also creates the filter userMatch that finds messages from facility auth that do not contain operator.
This configuration also creates the output buffer log, which uses both filters.
Messages that are matched must be from the source local6 and contain the word hostname or they must be from the source auth and not contain the word operator.
--{ * candidate shared default }--[ ]--
# info with-context system logging
system {
logging {
filter hostnameMatch {
contains hostname
facility local6 {
}
}
filter userMatch {
not-contains operator
facility auth {
}
}
buffer log {
filter [
hostnameMatch
userMatch
]
}
}
}
Request output filter and facility
The following example creates the filter hostnameMatch that finds messages from facility local6 that contain the word hostname.
This configuration also creates the output buffer log, which uses the filter and includes all messages from facility auth.
Messages that are matched must be from the source local6 and contain the word hostname or facility auth.
--{ * candidate shared default }--[ ]--
# info with-context system logging
system {
logging {
filter hostnameMatch {
facility local6 {
}
}
buffer log {
filter [
hostnameMatch
]
facility auth {
}
}
}
Request output dual-filter and facility and subsystem
The following example creates the filter hostnameMatch that finds messages from facility local6 that contain the word hostname.
This configuration also creates the output buffer log, which uses the filter and includes all messages from facility auth and all messages from subsystem aaa.
Messages that are matched must be from the source local6 and contain the word hostname or facility auth or subsystem aaa.
--{ * candidate shared default }--[ ]--
# info with-context system logging
system {
logging {
filter hostnameMatch {
contains hostname
facility local6 {
}
}
buffer log {
filter [
hostnameMatch
]
facility auth {
}
subsystem aaa {
}
}
}
}
Logging destination configuration
You can configure the SR Linux to send logging information to the following destinations:
- log file
- memory buffer storage
- 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 four files).
Send critical cron messages to a file
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 with context system logging
system {
logging {
file cron-critical {
facility cron {
priority {
match-exact [
critical
]
}
}
}
}
}
Send messages matching a filter to a file
The following example sends messages matching criteria specified in filter f1 to the file /var/log/srlinux/file/f1-match:
--{ * candidate shared default }--[ ]--
# info with context system logging
system {
logging {
file fl-match {
filter [
f1
]
}
}
}
Send specific message types to a file
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 with context system logging
system {
logging {
file aaa-warn-info {
subsystem aaa {
priority {
match-exact [
warning
informational
]
}
}
}
}
}
Specifying a buffer destination
You can configure SR Linux to 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 with context 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 with context 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 with context system logging
system {
logging {
network-instance mgmt
remote-server 192.168.0.3 {
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 the Log Events Guide for more information about SR Linux logging subsystem names) are logged to the same Linux syslog facility. This behavior 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 with context system logging
system {
logging {
subsystem-facility local7
}
}
Specifying FQDN for logging hostnames
SR Linux allows you to configure the logging system to use either the system hostname or the system FQDN in the hostname field of the message
The following example configures SR Linux to use the system FQDN for logging messages.
--{ * candidate shared default }--[ ]--
# info with context system logging
system {
logging {
use-fqdn true
}
}
When the use-fqdn option is set to true, the system
FQDN is used in the syslog server hostname field. The default is
false. This ensures backward compatibility with previous
releases that only supported using the system hostname for logging messages. The
domain name must be configured for the FQDN to take effect. See Configuring a domain name.
Rsyslog templates for local buffer, file, or console output
log_mgr application supports the following rsyslog templates for local
buffer, file, or console output.RSYSLOG_DebugFormatRSYSLOG_TraditionalFileFormatRSYSLOG_FileFormat
Using RSYSLOG_DebugFormat
The RSYSLOG_DebugFormat template is mainly meant for debugging and
diagnostic purposes and must not be used for remote forwarding or production
environment.
--{ * candidate shared default }--[ ]--
# info with context system logging file messages
system {
logging {
file messages {
format RSYSLOG_DebugFormat
rotate 3
size 10000000
facility local6 {
priority {
match-above warning
}
}
}
}
}
Using RSYSLOG_TraditionalFileFormat
The message
formatRSYSLOG_TraditionalFileFormat
has low-precision timestamps.
--{ * candidate shared default }--[ ]--
# info with context system logging file messages
system {
logging {
file messages {
format RSYSLOG_TraditionalFileFormat
rotate 3
size 10000000
facility local6 {
priority {
match-above warning
}
}
}
}
}
Using RSYSLOG_FileFormat
The default message format RSYSLOG_FileFormat supports
high-precision timestamps and timezone information, as described in RFC
3339.
--{ * candidate shared default }--[ ]--
# info with context system logging file messages
system {
logging {
file messages {
format RSYSLOG_FileFormat
rotate 3
size 10000000
facility local6 {
priority {
match-above warning
}
}
}
}
}
Rsyslog templates for forwarding messages to remote servers
log_mgr application supports the following rsyslog templates for
forwarding messages to remote servers.RSYSLOG_ForwardFormatRSYSLOG_SyslogProtocol23FormatRSYSLOG_TraditionalForwardFormat
Using RSYSLOG_ForwardFormat
The message format
RSYSLOG_ForwardFormat forwards logs with high-precision
timestamps.--{ * candidate shared default }--[ ]--
# info with context system logging remote-server 192.0.2.1 format
system {
logging {
remote-server 192.0.2.1 {
format RSYSLOG_ForwardFormat
}
}
}
Using RSYSLOG_SyslogProtocol23Format
The message format RSYSLOG_SyslogProtocol23Format guarantees
reliable and efficient logging of important system events. This default message
format is defined in IETF internet-draft ietf-syslog-protocol-23 and
closely adheres to the syslog standard RFC5424.
--{ * candidate shared default }--[ ]--
# info with context system logging remote-server 192.0.2.1 format
system {
logging {
remote-server 192.0.2.1 {
format RSYSLOG_SyslogProtocol23Format
}
}
}
Using RSYSLOG_TraditionalForwardFormat
The message format RSYSLOG_TraditionalForwardFormat forwards logs
with low-precision timestamps.
--{ * candidate shared default }--[ ]--
# info with context system logging remote-server 192.0.2.1 format
system {
logging {
remote-server 192.0.2.1 {
format RSYSLOG_TraditionalForwardFormat
}
}
}
TLS encryption support
SR Linux supports encrypting rSyslog traffic using TLS. rSyslog includes support for the OpenSSL driver, which enables TLS based transport. TLS is optional and is enabled only when selected as the transport type by the operator.
To enable TLS, you must create a TLS profile and ensure it is accessible to rSyslog. This profile allows rSyslog to link to the required certificate and key files specified in the configuration.
By default, rSyslog uses port 514 for non-TLS traffic and port 6514 for TLS traffic, unless the user explicitly configures a different port. For a configuration example, see Configuring TLS on rSyslog log events.
Configuring TLS on rSyslog log events
To configure TLS encryption, set the transport parameter to
tls in the system logging remote-server{.host}
context and configure a TLS profile for the remote server.
The following example shows a configuration that enables TLS encryption using the
clab-profile TLS profile on port 6514. The logs are
formatted according to the RSYSLOG_SyslogProtocol23Format standard.
The transport parameter is set to tls,
specifying that TLS encryption should be used for the connection.
--{ * candidate shared default }--[ ]--
# info with-context system logging remote-server 192.168.0.3
system {
logging {
remote-server 192.168.0.3 {
transport tls
tls-profile clab-profile
remote-port 6514
source-address 192.168.0.3
format RSYSLOG_SyslogProtocol23Format
}
}
}
Facility alarms
Facility alarms indicate potential service-impacting problems with hardware components such as cards, fans, power supplies, and ports in the system.
CLI show commands and state allow the user to identify current facility alarm conditions without searching event logs or monitoring various card and port status to determine the health of hardware components in the system.
Facility alarms are documented in the SR Linux Log Events Guide with "Raising event" and "Clearing event" fields.
This chapter uses the terms "alarm" or "alarms" as a short form for "facility alarms".
Facility alarms versus log events
Facility alarms are different from log events. Facility alarms are generated with a raising event for the failure and a clearing event for the resolution. A log event occurs when the state of some object in the system changes. Log events notify the user of a state change, for example, a port going down, an IGP peering session coming up, and so on. Facility alarms can be examined at any time by the user, whereas log events are sent by a router asynchronously when they occur.
| Syslog severity status | Alarm severity status |
|---|---|
| Emergency | Critical |
| Alert | Critical |
| Critical | Major |
| Error | Minor |
| Warning | Warning |
| Notice | Warning |
| Info | — |
| Debug | — |
Facility alarm severities and alarm LED behavior
- Critical – solid red indicates that a critical alarm is raised or a critical external alarm input is detected
- Major – solid red indicates that a major alarm is raised or a major external alarm input is detected
- Minor – solid amber indicates that a minor alarm is raised or a minor external alarm input is detected
- Warning – there is no LED for warning alarms
On platforms that do not have alarm LEDs, the Stat LED is solid amber when there is a critical alarm.
Facility alarm configuration
Facility alarms are enabled by default with the following configuration:
--{ running }--[ ]--
# info detail with-context system alarms
system {
alarms {
admin-state enable
}
}
Displaying facility alarms
--{ running }--[ ]--
# show system alarms
===============================================================================================
Alarms [critical 1, major 1, minor 0, warning 0, total 0]
===============================================================================================
Time Created Severity Application
Resource
Event Name: Message
-----------------------------------------------------------------------------------------------
2026-06-18T23:07:51.787Z (a minute ago) critical platform
slot 6|type fan-tray
airflowMismatch: The fan-tray in slot 6 does not match the airflow of other modules in the system
2026-06-18T23:07:52.031Z (a minute ago) major platform
slot 6|type fan-tray
componentFailed: Component fan-tray 6 has failed, reason Fantray airflow misaligned
===============================================================================================