In this post we will cover the basics of Event Logging in Linux systems. We will talk about Syslog: Message structure, the most famous implementations and main configurations. We will also play with the inner workings of Linux logging using UNIX sockets, logger and syslog services.
Let’s get to it!
Syslog is a standard (RFC5424) used for log management. This management can be local or remote. Do not confuse syslog standard with syslog applications like Syslog-ng, Rsyslog, Nxlog…
In some of the most famous Linux distros like Ubuntu, Debian or Fedora, Rsyslog is installed by default. This application can be used for local or remote log management.
Syslog message structure is similar to this:
PRI value is calculated using the facility and priority values (see tables and formula below). Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Facility values MUST be in the range of 0 to 23 inclusive.
The formula we will use to calculate the PRI is:
This result will be between 0 and 191.
We already know the standard syslog message structure. Now, how are these messages managed?
In Linux environments we have a special type of files called “UNIX sockets”. These files are used to transfer information between processes. Processes will read and write data to the socket in order to communicate. In Debian we can list UNIX sockets with the following command:
In our case, applications will write their log messages into this Syslog dedicated socket. Rsyslog service (in Debian/Ubuntu/Fedora) will be “listening” (reading) from this socket. Every new log entry will then be processed according to Rsyslog configuration (later mentioned).
We can send a random message to this socket in order to test our Rsyslog configuration:
Note that you can specify a PRI with the following command: “logger -p kern.err hola”
As we have just seen, Rsyslog must be always listening to any log income from syslog UNIX socket. In order to achieve this, Rsyslog service must be always up and running (obviously). You can check its status with the following command:
One of our main questions is: Which criteria does Rsyslog use to classify and store logs in different files under /var/log? Can this location be modified?
Of course. Rsyslog behaviour is defined in its configuration file and can be easily modified:
This is some of its contents by default:
The storage rules are defined in the first lines following this syntax:
For example, by defining:
All cron facility logs of any severity will be stored under /var/log/cron.log
If we want to send these logs to a remote machine (usually a Log Collector) we will use the following settings (depending on if we want to use TCP or UDP):
In general, it is suggested to use TCP syslog since it is way more reliable than UDP. Keep in mind that in case of network congestion, messages might be dropped. We UDP these logs will be lost, but with TCP they will be resend after the network issue. Also note that a TLS option is available in order to send logs, but only with TCP. Nevertheless, TCP is not fully reliable and might also introduce some losses (see this post about TCP reliability). In order to increase reliability, see the RELP protocol from Rsyslog (See below) or the standard RFC3195.
In order to use it, install rsyslog-relp in both client and server (collector). In Debian:
Then you should add a couple of lines in the config files:
Then make sure you restart Rsyslog service in both machines.
RELP is not part of standard yet and has only been implemented in the following applications:
Even though the destination files are fully configurable -as we have just seen-, we will try to maintain some standard names and log files under our /var/log directory:
Log rotation is the action of saving (usually compressed) old logs for a determined amount of time. In Debian we can achieve this with “logrotate”. This is one of its configuration files (under /etc/logrotate.d/), for Rsyslog it is pretty self-explanatory:
We have seen the basic structure of Syslog messages with its different categories and severities.
Also, we have played with Linux log management and Rsyslog configurations in order to understand its inner workings. In the next post we will introduce Journald, a “new” log manager for Linux. We will see the new features it brings compared to Rsyslog, but also its deficiencies.
Thanks for reading!