How to set up your Raspberry Pi as a Syslog server

Based on the vast and informative article contents published on this platform, by now, you know a thing or two about the Raspberry Pi SBC (Single Board Computer). You are also aware that you can optionally choose and configure whichever Raspberry Pi-supported Operating System you think should be on the front line of your SBC-based projects. Additionally, we also have a detailed guide on configuring your Raspberry Pi projects to work with a database system like SQLite. In short, we will comfortably nurture and mentor you as you make your first SBC baby steps.

The next puzzle on our list today regarding the Raspberry Pi SBC is unraveling the Syslog server’s mysteries and its relationship to a Raspberry Pi-powered project. Firstly, we need to handle its definition before installing and configuring it in a Raspberry Pi environment.

What is a Syslog server?

Syslog, in plain terms, is an acronym-like abbreviation for System Logging Protocol. A network device needs a way of sending and receiving messages with a logging server. This communication is important for monitoring the performance or behavior of the active network devices. A Raspberry Pi SBC is extensive and flexible enough to be configured with such a network device’s characteristics. When the communication between a logging server and a network device is underway, certain communication protocols are implemented for the message notifications to reach the intended target. One of the communication protocols in play is the activeness of a Syslog agent responsible for the dispatch of these message notifications.

The dispatched message log details include specific network event information and network device ID merged/masked with its IP address, an event severity rating, and an event timestamp. We might not describe these Syslog protocols as completely perfect, but its user community’s continuous positive appraise because of its simple implementation. The primary selling factor of these Syslog server protocols implementation is the Syslog server’s open-ended nature. This server attribute caters to a variety of proprietary implementations, making it possible to assess and monitor the activities of any device connected to the linked active network environment.

Syslog support for Unix and Linux flavors makes it a perfect candidate to configure with a Raspberry Pi board. If you are familiar with the daemon server process, you have some idea about the Syslog server processes’ operability.

The importance of Logging

In a Syslog environment, where the log server is running, you have the advantage and flexibility of monitoring various Syslog events at once through availed log files. The connected network devices are responsible for the generation of the log messages saved on these log files. These connected network devices include other servers, printers, firewalls, switches, and routers. When these network devices relay these log messages, the Syslog server will receive, categorize, and store them for analysis. This Syslog server performance approach creates and maintains a comprehensive view regarding a targeted network activity or the entire active network spectrum. So, in case of an unexpected network device malfunction, you will need to use the log file messages to find a viable diagnosis of the network issue.

Syslog messages, data collection, and management

Before we dive into this article’s objective and learn how to set up Raspberry Pi with a Syslog server, it is also important to understand the mechanisms of Syslog messages, data collection, and management.

The protocol responsible for relaying Syslog messages is none other than UDP (User Diagram Protocol). UDP is functional via port 514. Many networking professionals refer to UDP as a connectionless protocol. This naming convention relates to the fact that the generated network devices’ messages might not arrive at the Syslog server, and if they do, they might not be acknowledged by the same Syslog server. UDP is depicted as a gamble when dealing with Syslog messages. On the other hand, it is a preference because it does not complicate the network system infrastructure making it easy to work with and manage.

Most of the time, the Syslog messages will be generated or relayed in a human-readable format. It is not a mandatory mode of relaying these logging messages as they can be changed to other formats. During a message relay, the Syslog message header includes a priority level of the carrying message. This message priority level is a breakdown of the specific network device’s severity level and its process code that resulted in the Syslog message generation. The prominent severity levels are presented by the process codes 0,1 6, and 7. Process code 0 is for emergency messages, process code 1 for immediate attention messages, process code 6 for informational messages, and process code 7 for debug messages. It is fairly easy to classify and interpret a solution to a Syslog message with these process codes.

Data collection and management is an important aspect of the operational cycle of a Syslog server. On an active network setup or infrastructure, a network administrator always expects cumulative Syslog data logs. It is due to a large amount of generated and retained Syslog messages. For this reason, the system database configured and assigned to a Syslog server needs to be large enough. The consideration of management and filtering software is also a necessity in this case. Reason? The software will be responsible for automating the generation of related notifications, alarms, and alerts. Filtering is also an important aspect of this software. Files from specific sources like a firewall will be easy to retrieve through a sysadmin and assessed for a specified timeframe.

This management and filtering software should also provide an interface for remote text messages and on-screen popups. This functionality upgrade or improvement is important to a sysadmin in dealing with network functionalities or processes diverging from the norm. For instance, if a particular network device is raising concerns, a viable approach or solution would be to lower its network threshold value, monitoring the lower severity messages possible.

Now that we understand the concept of Syslog messages, the resulting Syslog data, if applied correctly, will help better assess the performance of the actively configured network devices. The Syslog data helps you better understand your network infrastructure by generating network-related diagrams and detailed reporting. Since we mentioned the usefulness of a management and filtering software to run alongside a Syslog server, a familiar practical software case is SIEM (Security Information and Event Management). It effectively tracks, integrates, and analyzes Syslog data collections with an original focus on compliance reporting.

Differing Syslog flavors

Before we jump into Syslog server installation on Raspberry Pi, it is important to note the variety of Syslog flavors. We have Syslog as the main or original recipe with rsyslog and syslog-ng as the optional alternative flavors.

The syslog-ng functional design consists of improved encryption and filtering functions. It does not use the same syntax rules as Syslog despite their close functional and derivation relations. You will find these two server configurations varying.

Rsyslog is a direct derivative from Syslog, making it an ideal alternative to using and implementing the syslog.conf and rsyslog.conf configuration files are interchangeable. For this reason, this article will be leaning more towards the use of rsyslog than syslog-ng. Both these servers are applicably compatible in UDP, RELP, TLS, TCP configured environments.

Configuring your Raspberry Pi SBC to be a Syslog server using rsyslog

This step of the tutorial assumes you have an active network device like a home router. You want to enable it to forward log messages to an actively configured Syslog server. For this tutorial, we will use the rsyslog daemon server to accomplish the article’s objective. It is due to its compatibility with the original Syslog server.

The prerequisites to consider for this tutorial are that your Raspberry Pi SBC is configured with a Raspbian Operating System. The network device in use is flexibly compatible to accommodate the needed Syslog protocols.

Step 1: Installing the rsyslog server

The first step is installing the rsyslog service on your Raspberry Pi SBC. Launch the Raspbian OS terminal or command-line and key-in the following commands.

$ sudo apt install rsyslog

Step 2: Enabling port 514 on your Raspberry Pi SBC

This step is self-explanatory since we already mentioned how Raspberry Pi relates to port 514. It is the default listening port that your Pi board will use to communicate with the rsyslog server connections. It is an important step that, if forgotten, might make you think your Pi board has compatibility issues with the rsyslog server. To make the mentioned port 514 active, you will need to access the following rsyslog configuration file.

/etc/rsyslog.conf

You can open this file via the following command.

$ sudo nano /etc/rsyslog.conf

Afterward, make sure the following configuration lines remain uncommented by removing the # symbol that precedes them.

# provides UDP syslog reception

# module(load="imudp")

# input (type="imudp" port="514")

# provides TCP syslog reception

# module (load="imtcp")

# input (type="imtcp" port="514")

There is an exception to the usage of this port 514. It is not mandatory that your Raspberry Pi has to use it to communicate with the installed Syslog server. You can configure whichever port you want to use as long as another system service is not using it. Port 514 is optionally assigned by the Syslog server as a means of saving you from the headaches of finding a vacant port to avoid port conflicts. After you are done uncommenting the specified lines of code, press Ctrl+X on your keyboard, then Y, and finally, hit Enter on the same keyboard. You will have saved the necessary changes on the Syslog configuration file.

Step 3: Creating a log file

Since the Syslog server will generate Syslog messages, they are important in troubleshooting a diagnostic solution to the connected network devices. The Syslog server does not know what to do with these messages after it is done transmitting them. If we can manage to capture these message packets and store them somewhere for future reference, we would be efficient enough in backtracking all the issues related to the active network devices. Thus, we need to have a log file for storing the captured Syslog message packets. The default storage location for these Syslog files is the directory path:

/var/log

We can be specific on where these Syslog messages should be stored by defining our log file. Run the following command on your Raspbian OS terminal.

$ sudo touch /var/log/netdevices.log

Step 4: Configuring logs

Now that we have the custom log file we want to use created, the next step is informing the rsyslog server about the existence of this file and our intentions about its usage. To achieve this objective, we will create another configuration file inside the following directory:

/etc/rsyslog.d

This file can take any naming convention you like:

$ sudo touch nano /etc/rsyslog.d/netgear.conf

On my end, I named the file netgear.conf because I want my Raspberry Pi board to communicate with a Netgear router I have configured. The information that goes into this file relates to the active network device I am using. Populate the newly created configuration file on your end with information similar to this one.

#/etc/rsyslog.d/netgear.conf

$template NetworkLog, "/var/log/netdevices.log"

:fromhost-ip, isequal, "192.168.0.10" -?Networking

& stop

As you populate the above .conf file, make sure the IP address you enter is of the network device you have configured on your end. We instruct the Syslog server to send any Syslog messages; related to the network device with the specified IP address to the user-defined log file /var/log/netdevices.log.

Step 5: Restart the rsyslog server

You will need to restart the rsyslog server to acknowledge the changes and configurations we have made so far. You can achieve this objective by running the following command on your Raspbian OS terminal.

$ sudo service rsyslog restart

Step 6: Initializing the Syslog protocol via your active network device

The Syslog protocol on your Raspberry Pi board should be correctly configured and functional at this point. We now need the active network device on your end to also acknowledge this Syslog protocol too. Initiating this step varies with different network device firmware versions. Because of this reason, it is important to be well acquainted with your network device documentation or user manual. On my end, the IP address I provided under the user-defined /etc/rsyslog.d/netgear.conf configuration file was enough to start the network protocol.

Step 7: Configuring logrotate

You will need to create a file inside the directory /etc/logrotate.d/ for this configuration.

$ sudo touch /etc/logrotate.d/netdevices.log

This configuration step is optional but recommended. Rotating your log file helps deal with the many log entries that network devices like routers present. The file created above can have any naming convention. The contents of this file should be similar to the following:

/var/log/netdevices.log {

          rotate 7

          size 500k

          notifempty

          compress

          postrotate

                 invoke-rc.d rsyslog rotate > /dev/null 

          endscript

}

The first line of the log file points to the file we created in the /var/log directory.

Step 8: Checking rsyslog status

Run the following command on your Raspbian OS terminal.

$ sudo service rsyslog status

This command tells us whether our rsyslog configuration was successful and everything is working as expected. The terminal outcome should have a segmented instance like the following:
active (running)
This command outcome tells you that your Raspberry Pi board is perfectly operational as a Syslog server.

Final note

With this brief yet detailed tutorial, you can add more network devices and configure them to work with the Raspberry Pi board. You now understand the rules of the Syslog world and the important configurations that need implementation. With the Raspberry Pi board as your projects’ playground, you should be able to test and gauge the various Syslog messages related to your configured network devices. The performance and issues related to these devices will be easy to breakdown and diagnose. Learning how to use a Syslog server is a solid step in understanding a network infrastructure’s metrics.