Direct System Log Messages to a Remote Destination

Each system log message belongs to a facility, which groups together messages that either are generated by the same source (such as a software process) or concern a similar condition or activity (such as authentication attempts). Each message is also preassigned a severity level, which indicates how seriously the triggering event affects routing platform functions.

When you configure logging for a facility and destination, you specify a severity level for each facility. Messages from the facility that are rated at that level and higher are logged to the following destination:

For more information about the destinations, see Directing System Log Messages to a User Terminal, and, Directing System Log Messages to the Console.

To log messages belonging to more than one facility to a particular destination, specify each facility and associated severity as a separate statement within the set of statements for the destination.

Table 1 lists the Junos OS system logging facilities that you can specify in configuration statements at the [edit system syslog] hierarchy level.

Table 1: Junos OS System Logging Facilities

Facility	Type of Event or Error
any	All (messages from all facilities)
authorization	Authentication and authorization attempts
change-log	Changes to the Junos OS configuration
conflict-log	Specified configuration is invalid on the router type
daemon	Actions performed or errors encountered by system processes
dfc	Events related to dynamic flow capture
explicit-priority	Include priority and facility in system log messages
external	Actions performed or errors encountered by the local external applications
firewall	Packet filtering actions performed by a firewall filter
ftp	Actions performed or errors encountered by the FTP process
interactive-commands	Commands issued at the Junos OS command-line interface (CLI) prompt or by a client application such as a Junos XML protocol or NETCONF XML client
kernel	Actions performed or errors encountered by the Junos OS kernel
ntp	Actions performed or errors encountered by the Network Time Protocol processes
pfe	Actions performed or errors encountered by the Packet Forwarding Engine
security	Security related events or errors
user	Actions performed or errors encountered by user-space processes

Table 2 lists the severity levels that you can specify in configuration statements at the [edit system syslog] hierarchy level. The levels from emergency through info are in order from highest severity (greatest effect on functioning) to lowest.

Unlike the other severity levels, the none level disables logging of a facility instead of indicating how seriously a triggering event affects routing functions. For more information, see Disabling the System Logging of a Facility.

Table 2: System Log Message Severity Levels

Value	Severity Level	Description
N/A	none	Disables logging of the associated facility to a destination
0	emergency	System panic or other condition that causes the router to stop functioning
1	alert	Conditions that require immediate correction, such as a corrupted system database
2	critical	Critical conditions, such as hard errors
3	error	Error conditions that generally have less serious consequences than errors at the emergency, alert, and critical levels
4	warning	Conditions that warrant monitoring
5	notice	Conditions that are not errors but might warrant special handling
6	info	Events or nonerror conditions of interest
7	any	Includes all severity levels

To direct system log messages to a file in the /var/log directory of the local Routing Engine, include the file statement at the [edit system syslog] hierarchy level:

For the list of facilities and severity levels, see Specifying the Facility and Severity of Messages to Include in the Log.

To prevent log files from growing too large, the Junos OS system logging utility by default writes messages to a sequence of files of a defined size. By including the archive statement, you can configure the number of files, their maximum size, and who can read them, either for all log files or for a certain log file. For more information, see Specifying Log File Size, Number, and Archiving Properties.

For information about the following statements, see the indicated sections:

• explicit-priority—See Including Priority Information in System Log Messages

• match—See Using Strings and Regular Expressions to Refine the Set of Logged Messages

• structured-data—See Logging Messages in Structured-Data Format

To direct system log messages to the terminal session of one or more specific users (or all users) when they are logged in to the local Routing Engine, include the user statement at the [edit system syslog] hierarchy level:

Specify one or more Junos OS usernames, separating multiple values with spaces, or use the asterisk (*) to indicate all users who are logged in to the local Routing Engine.

For the list of logging facilities and severity levels, see Specifying the Facility and Severity of Messages to Include in the Log. For information about the match statement, see Using Strings and Regular Expressions to Refine the Set of Logged Messages.

To direct system log messages to the console of the local Routing Engine, include the console statement at the [edit system syslog] hierarchy level:

For the list of logging facilities and severity levels, see Specifying the Facility and Severity of Messages to Include in the Log.

To direct system log messages to a remote machine or to the other Routing Engine, include the host statement at the [edit system syslog] hierarchy level:

To direct system log messages to a remote machine, include the host hostname statement to specify the remote machine’s IP version 4 (IPv4) address, IP version 6 (IPv6) address, or fully qualified hostname. The remote machine must be running the standard syslogd utility. We do not recommend directing messages to another Juniper Networks device. In each system log message directed to the remote machine, the hostname of the local Routing Engine appears after the timestamp to indicate that it is the source for the message.

To direct system log messages to the other Routing Engine on a device with two Routing Engines installed and operational, include the host other-routing-engine statement. The statement is not automatically reciprocal, so you must include it in each Routing Engine configuration if you want the Routing Engines to direct messages to each other. In each message directed to the other Routing Engine, the string re0 or re1 appears after the timestamp to indicate the source for the message.

For the list of logging facilities and severity levels to configure under the host statement, see Specifying the Facility and Severity of Messages to Include in the Log.

To record facility and severity level information in each message, include the explicit-priority statement. For more information, see Including Priority Information in System Log Messages.

For information about the match statement, see Using Strings and Regular Expressions to Refine the Set of Logged Messages.

When directing messages to remote machines, you can include the source-address statement to specify the IP address of the device that is reported in the messages as their source. In each host statement, include the facility-override statement to assign an alternative facility and the log-prefix statement to add a string to each message. You can include the structured-data statement to enable the forwarding of structured system log messages to a remote system log server in the IETF system log message format.

To specify the source router to be reported in system log messages when the messages are directed to a remote machine, include the source-address statement at the [edit system syslog] hierarchy level:

source-address is a valid IPv4 or IPv6 address configured on one of the router interfaces. The address is reported in the messages directed to all remote machines specified in host hostname statements at the [edit system syslog] hierarchy level, but not in messages directed to the other Routing Engine.

To add a text string to every system log message directed to a remote machine or to the other Routing Engine, include the log-prefix statement at the [edit system syslog host] hierarchy level:

The string can contain any alphanumeric or special character except the equal sign ( = ) and the colon ( : ). It also cannot include the space character; do not enclose the string in quotation marks (“ ”) in an attempt to include spaces in it.

The Junos OS system logging utility automatically appends a colon and a space to the specified string when the system log messages are written to the log. The string is inserted after the identifier for the Routing Engine that generated the message.

The following example shows how to add the string M120 to all messages to indicate that the router is an M120 router, and direct the messages to the remote machine hardware-logger.mycompany.com:

When these configuration statements are included on an M120 router called origin1, a message in the system log on hardware-logger.mycompany.com looks like the following:

Some facilities assigned to messages logged on the local router or switch have Junos OS-specific names (see Junos OS System Logging Facilities). In the recommended configuration, a remote machine designated at the [edit system syslog host hostname] hierarchy level is not a Juniper Networks router or switch, so its syslogd utility cannot interpret the Junos OS-specific names. To enable the standard syslogd utility to handle messages from these facilities when messages are directed to a remote machine, a standard localX facility name is used instead of the Junos OS-specific facility name.

Default Facilities for System Log Messages Directed to a Remote Destination lists the default alternative facility name next to the Junos OS-specific facility name it is used for.

The syslogd utility on a remote machine handles all messages that belong to a facility in the same way, regardless of the source of the message (the Juniper Networks router or switch or the remote machine itself). For example, the following statements in the configuration of the router called local-router direct messages from the authorization facility to the remote machine monitor.mycompany.com:

The default alternative facility for the local authorization facility is also authorization. If the syslogd utility on monitor is configured to write messages belonging to the authorization facility to the file /var/log/auth-attempts, then the file contains the messages generated when users log in to local-router and the messages generated when users log in to monitor. Although the name of the source machine appears in each system log message, the mixing of messages from multiple machines can make it more difficult to analyze the contents of the auth-attempts file.

To make it easier to separate the messages from each source, you can assign an alternative facility to all messages generated on local-router when they are directed to monitor. You can then configure the syslogd utility on monitor to write messages with the alternative facility to a different file from messages generated on monitor itself.

To change the facility used for all messages directed to a remote machine, include the facility-override statement at the [edit system syslog host hostname] hierarchy level:

In general, it makes sense to specify an alternative facility that is not already in use on the remote machine, such as one of the localX facilities. On the remote machine, you must also configure the syslogd utility to handle the messages in the desired manner.

Facilities for the facility-override Statement lists the facilities that you can specify in the facility-override statement.

We do not recommend including the facility-override statement at the [edit system syslog host other-routing-engine] hierarchy level. It is not necessary to use alternative facility names when directing messages to the other Routing Engine, because its Junos OS system logging utility can interpret the Junos OS-specific names.

The following example shows how to log all messages generated on the local router at the error level or higher to the local0 facility on the remote machine called monitor.mycompany.com:

The following example shows how to configure routers located in California and routers located in New York to send messages to a single remote machine called central-logger.mycompany.com. The messages from California are assigned to alternative facility local0 and the messages from New York are assigned to alternative facility local2.

• Configure California routers to aggregate messages in the local0 facility:

• Configure New York routers to aggregate messages in the local2 facility:

On central-logger, you can then configure the system logging utility to write messages from the local0 facility to the file change-log and the messages from the local2 facility to the file new-york-config.

You can configure a routing matrix composed of a TX Matrix router and T640 routers to direct system logging messages to a remote machine or the other Routing Engine on each router, just as on a single-chassis system. Include the host statement at the [edit system syslog] hierarchy level on the TX Matrix router:

The TX Matrix router directs messages to a remote machine or the other Routing Engine in the same way as a single-chassis system, and the optional statements (explicit-priority, facility-override, log-prefix, match, and source-address) also have the same effect as on a single-chassis system.

For the TX Matrix router to include priority information when it directs messages that originated on a T640 router to the remote destination, you must also include the explicit-priority statement at the [edit system syslog host scc-master] hierarchy level.

The other-routing-engine statement does not interact with message forwarding from the T640 routers to the TX Matrix router. For example, if you include the statement in the configuration for the Routing Engine in slot 0 (re0), the re0 Routing Engine on each T640 router sends messages to the re1 Routing Engine on its platform only. It does not also send messages directly to the re1 Routing Engine on the TX Matrix router.

Because the configuration on the TX Matrix router applies to the T640 routers, any T640 router that has interfaces for direct access to the Internet also directs messages to the remote machine. The consequences include the following:

• If the T640 routers are configured to forward messages to the TX Matrix router (as in the default configuration), the remote machine receives two copies of some messages: one directly from the T640 router and the other from the TX Matrix router. Which messages are duplicated depends on whether the severities are the same for local logging and for forwarded messages. For more information, see Configuring Message Forwarding to the TX Matrix Router.

• If the source-address statement is configured at the [edit system syslog] hierarchy level, all routers in the routing matrix report the same source address in messages directed to the remote machine. This is appropriate, because the routing matrix functions as a single router.

• If the log-prefix statement is included, the messages from all routers in the routing matrix include the same text string. You cannot use the string to distinguish between the routers in the routing matrix.

From the perspective of the user interface, the routing matrix appears as a single router. The TX Matrix Plus router (also called the switch-fabric chassis SFC) controls all the T1600 or T4000 routers also called the ine-card chassis LCC) in the routing matrix.

You can configure a routing matrix composed of a TX Matrix Plus router with connected T1600 or T4000 LCCs to direct system logging messages to a remote machine or the other Routing Engine on each routing router, just as on a single-chassis system. Include the host statement at the [edit system syslog] hierarchy level on the SFC:

The TX Matrix Plus router directs messages to a remote machine or the other Routing Engine in the same way as a single-chassis system, and the optional statements (explicit-priority, facility-override, log-prefix, match, and source-address) also have the same effect as on a single-chassis system.

For the TX Matrix Plus router to include priority information when it directs messages that originated on a connected T1600 or T4000 LCC to the remote destination, you must also include the explicit-priority statement at the [edit system syslog host sfc0-master] hierarchy level.

The other-routing-engine statement does not interact with message forwarding from the connected T1600 or T4000 LCCs to the SFC. For example, if you include the statement in the configuration for the Routing Engine in slot 0 (re0), the re0 Routing Engine on each connected T1600 or T4000 LCC sends messages to the re1 Routing Engine on its router only. It does not also send messages directly to the re1 Routing Engine on the SFC.

Because the configuration on the SFC applies to the connected T1600 or T4000 LCCs, any LCC that has interfaces for direct access to the Internet also directs messages to the remote machine. The consequences include the following:

• If the LCCs are configured to forward messages to the SFC (as in the default configuration), the remote machine receives two copies of some messages: one directly from the T1600 or T4000 LCC and the other from the SFC. Which messages are duplicated depends on whether the severities are the same for local logging and for forwarded messages. For more information, see Configuring Message Forwarding to the TX Matrix Plus Router.

• If the source-address statement is configured at the [edit system syslog] hierarchy level, all routers in the routing matrix report the same source address in messages directed to the remote machine. This is appropriate, because the routing matrix functions as a single routing router.

• If the log-prefix statement is included, the messages from all routers in the routing matrix include the same text string. You cannot use the string to distinguish between the routers in the routing matrix.