Raspberry Pi as a Syslog Server

Syslog has its roots in the UNIX world. It served as the de facto logging solution for UNIX and Unix-like systems for a long time. Today, syslog is a very popular and simple mechanism for managed devices like routers and switches to generate event messages. In this article, we will provide an introduction to the syslog protocol. We will also configure a Raspberry Pi system as syslog server to collect messages sent from managed network devices. The article should be of interest to network engineers, enthusiasts, and students alike.

What is Syslog?

Syslog is a client/server protocol that deals with the generation, transmission, and storage of system messages. The purpose of syslog, as the name indicates, is to write system messages to a log file. Each system message is supposed to result in an entry in the log file. A system administrator can analyze the messages in the log file as needed. The log file may be stored locally on the device generating system messages as well as on a remote logging host. The later solution is used more often as it preserves the messages in case of managed device failure. Management applications, posing as a logging host, can also receive syslog messages directly as they occur without having to retrieve entries from a log file. Syslog messages may be sent via User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) on port number 514.

Syslog messages can include everything from critical alarm conditions to routine debugging statements. They provide a trail of activities taking place inside your device whether it’s a router, switch, or server. Under normal operating conditions, syslog messages may not be of much use. However, the ability to trace device activity is invaluable under certain circumstances. These circumstances include conditions like severe degradation of services, erratic network behavior, and suspected network intrusion. Syslog messages are also useful when you need to debug or fine tune network deployments. Some devices are very chatty when it comes to syslog and generate a whole lot of messages. You can however filter syslog messages depending on what you are interested in and what you can afford to ignore.

Syslog can be considered a complement to the command line interface (CLI). Syslog messages are designed to be readable by human just like the CLI. The main difference between CLI and syslog is that syslog messages are auto generated by devices while CLI follows a request and response pattern.

Syslog Messages

Each syslog message constitutes a header and a body. The header contains very brief but essential information about the message itself. This information includes the time when the message was generated, name of the host that generated the message, severity level of the message, the subsystem (often referred to as facility) that generated the message, and a mnemonic. The mnemonic is nothing more than a short name for the type of message. The information in the header is not much but it is very structured making syslog messages useful to applications in addition to humans.

The message body is the informal part of a syslog message. It contains the message content that, unlike the header, is not subject to any structural constraints. The header may contain plain English text and in many cases it does contain plain English text. A syslog message starts with header and the body follows the header.

Here is an example of a syslog message commonly seen on Cisco routers as you exit the configuration mode.

Figure 1 Anatomy of a Syslog Message

The message components up to the colon, after SYS-5-CONFIG_I, are all part of the message header. The rest is the message body. Please keep in mind that the concept of facility as described here is specific to Cisco and is different from the facility defined in syslog RFCs. The facility here refers to the source of the message such as the hardware component, protocol, or software subsystem.

You can decide which messages are sent by syslog client devices based on the level of severity. These severity levels are standardized and are identified by a number and/or a standard abbreviation:

  • 0 – Emergency (emerg)
  • 1 – Alerts (alert)
  • 2 – Critical (crit)
  • 3 – Errors (err)
  • 4 – Warnings (warn)
  • 5 – Notification (notice)
  • 6 – Information (info)
  • 7 – Debug (debug)

Level 7 sends just every syslog message to the syslog server.

Syslog Deployment

A syslog deployment comprises two entities that are involved in the exchange of syslog messages. The syslog sender sends the syslog messages and it is a Cisco router in the scenario presented in this article. The syslog receiver is the recipient of syslog messages and we will configure a Raspberry Pi system in this role. Generally, the syslog sender acts as management agent while the syslog receiver corresponds to manager. However, syslog receivers do not actively manage a device. The syslog receiver is simply the passive receiving end of syslog message exchange responsible for logging the message to a file on disk. A syslog receiver can be the device itself, writing messages to a local log file. This log file can be viewed locally by a system administrator. It can also be transferred to an external management application over a protocol like Trivial File Transfer Protocol (TFTP) when desired.

A centralized logging host that can receive syslog messages from several devices is a more popular choice. Management applications can access this logging host instead of individual devices to access log records. System administrators can also turn to the logging host instead of individual devices to retrieve logs.

Figure 2 Raspberry Pi as a Syslog Server

Let’s first install SSH, a secure method of logging into a remote computer, to access and configure our Raspberry Pi system. It will enable us to run a headless Raspberry Pi system without the space consuming monitor and keyboard.

root@raspberrypi:/home/pi# apt-get install ssh
Reading package lists... Done
Building dependency tree
Reading state information... Done
ssh is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

The command above will install SSH for you, if it isn’t already installed. You can start the SSH daemon (UNIX name for what is known as service in the Windows world) with this command:

root@raspberrypi:/home/pi# /etc/init.d/ssh start
Starting OpenBSD Secure Shell server: sshd.

At this point, we have got SSH installed and can access the Pi remotely. Let’s turn our attention to the installation and configuration a syslog server on the Pi. We will then use the server to collect syslog messages from the router in our test scenario.

You should install the latest updates for apt-get or make sure that you are already using the most current version.

Be the first to hear of new free tutorials, training videos, product demos, and more. We'll deliver the best of our free resources to you each month, sign up here:
root@raspberrypi:/home/pi# apt-get update
Get:1 http://mirrordirector.raspbian.org wheezy InRelease [14.9 kB]
Get:2 http://archive.raspberrypi.org wheezy InRelease [7,761 B]
Get:3 http://mirrordirector.raspbian.org wheezy/main armhf Packages [7,414 kB]
Get:4 http://archive.raspberrypi.org wheezy/main armhf Packages [15.9 kB]

-- Some output omitted for brevity --

Fetched 7,453 kB in 3min 33s (35.0 kB/s)
Reading package lists... Done

We will use syslog-ng as our syslog server which is just a rewrite of the original syslog daemon with enhanced features. Syslog-ng is an open source implementation of syslog though a premium edition is also available under proprietary license.

root@raspberrypi:/home/pi# apt-get install syslog-ng
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libdbi1 libevtlog0 libmongo-client0 libnet1 libsyslog-ng-3.3.5 libsystemd-daemon0 syslog-ng-core syslog-ng-mod-json syslog-ng-mod-mongodb syslog-ng-mod-sql
Suggested packages:
mongodb-server libdbd-mysql libdbd-pgsql libdbd-sqlite3
The following NEW packages will be installed:
libdbi1 libevtlog0 libmongo-client0 libnet1 libsyslog-ng-3.3.5 libsystemd-daemon0 syslog-ng syslog-ng-core syslog-ng-mod-json syslog-ng-mod-mongodb
syslog-ng-mod-sql
0 upgraded, 11 newly installed, 0 to remove and 207 not upgraded.
Need to get 0 B/613 kB of archives.
After this operation, 2,158 kB of additional disk space will be used.
Do you want to continue [Y/n]? Y

-- Output omitted for brevity --

Setting up libmongo-client0:armhf (0.1.5-1+deb7u1) ...
Setting up libevtlog0 (0.2.12-5) ...
Setting up libsyslog-ng-3.3.5:armhf (3.3.5-4) ...
Setting up libsystemd-daemon0:armhf (44-11+deb7u4) ...
Setting up libdbi1 (0.8.4-6) ...
Setting up libnet1 (1.1.4-2.1) ...
Setting up syslog-ng-core (3.3.5-4) ...
Processing triggers for syslog-ng-core ...
Stopping system logging: syslog-ng.
Starting system logging: syslog-ng.
Setting up syslog-ng-mod-json (3.3.5-4) ...
Setting up syslog-ng-mod-sql (3.3.5-4) ...
Setting up syslog-ng-mod-mongodb (3.3.5-4) ...
Processing triggers for syslog-ng-core ...
Stopping system logging: syslog-ng.
Starting system logging: syslog-ng.
Setting up syslog-ng (3.3.5-4) ...

Syslog-ng is configured via the syslog-ng.conf file found in the /etc/syslog-ng directory. You need to edit that file so that the Pi can start receiving syslog messages from the Cisco router in our test scenario. You can open syslog-ng.conf for editing using a text editor like the good old nano. It would instantly become clear that file is well structured and has several sections. You can add the following three lines to the sections named Sources, Destinations, and Log paths respectively.

source s_net { udp(ip(0.0.0.0) port(514)); };
destination d_router { file("/var/log/router.log"); };
log { source(s_net); destination(d_router); };

Please keep in mind that you can also alternately the three lines together in the file and it still works. You need to restart syslog-ng to bring into effect the configuration changes you just made.

root@raspberrypi:/home/pi# service syslog-ng restart
Stopping system logging: syslog-ng.
Starting system logging: syslog-ng.

You can use the touch command to create the log file that will be used to write syslog messages from the router.

root@raspberrypi:/home/pi# touch /var/log/router.log
root@raspberrypi:/home/pi# ls /var/log/router*
/var/log/router.log

You can have a live view of the syslog messages that will be written to the router.log file using the tail command.

root@raspberrypi:/home/pi# tail -f /var/log/router.log

That’s all what we need to configure on the Pi.

Let’s turn our attention to the router. We basically need just a couple of configuration line on the router in order to make it start sending all syslog messages to the Pi.

R1>enable
Password:
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#logging trap 7
R1(config)#logging 192.168.1.2
R1(config)#end
R1#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
R1#

The command logging trap 7 above instructs the router to just send every syslog message with severity 7 (debug) or lower. The second configuration command logging 192.168.1.2 mentions the IP address 192.168.1.2 configured on the Ethernet interface of the Pi as the destination of syslog messages sent out.

You may verify your configuration using the command show logging.

R1#show logging
Syslog logging: enabled (0 messages dropped, 3 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)

-- Some output omitted for brevity --

Trap logging: level informational, 30 message lines logged
Logging to 192.168.1.2 (udp port 514, audit disabled,
link up),
12 message lines logged,
0 message lines rate-limited,
0 message lines dropped-by-MD,
xml disabled, sequence number disabled
filtering disabled

You may, for example, shut down an interface on the Cisco router and bring it up again in order to make the router emit some syslog messages. These and any other syslog messages emitted by the router should make their way to the Pi.

root@raspberrypi:/home/pi# tail -f /var/log/router.log
Dec 24 18:32:27 192.168.1.3 21: *Dec 24 18:29:10.741: %SYS-5-CONFIG_I: Configured from console by vty0 (192.168.1.144)
Dec 24 19:35:12 192.168.1.3 22: *Dec 24 19:31:56.301: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
Dec 24 19:35:12 192.168.1.3 23: *Dec 24 19:31:57.301: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up

Each syslog message includes the IP address of the syslog sender. In the present case, the IP address 192.168.1.3 which corresponds to the Cisco router. The IP address can be used to distinguish the syslog messages sent by different managed network devices.

An inexpensive Raspberry Pi system coupled with syslog-ng, a high performance syslog server, can thus be used for logging and aggregating messages from multiple managed devices.

The following two tabs change content below.

Muhammad Furqan

Muhammad Furqan, CCIE Routing & Switching, currently works as an engineer at a global provider of networking and information technology services. He has a degree in Computer Engineering and enjoys writing articles and tutorials on networking and related topics. Reach him at muhammad.furqan@gmail.com or connect with him on Twitter @MuhammadFurqan.