Skip to main content

Managing and filtering Syslog messages can reduce noise and highlight critical events. This blog post explains how the PRI value helps categorize messages by severity, describes syslog filtering, and shows how to use rsyslog in a Docker container to forward selected messages based on a filter.

What is the PRI value for, and why does it matter?

The Priority (PRI) value combines the facility and severity into a single numeric value. This value helps categorize Syslog messages. Each log message is assigned a Facility Code indicating its source, such as system processes, mail server, etc, and its severity. I could tell you from my memories and more about the origins of the Facility Codes 😉, but plenty of websites on the Internet describe this in detail. Veeam Backup & Replication leverages the user-level facility (Facility Code 1).

Next is the severity. The table below shows how different severities map within the user-level facility (not all severities are covered in this table):

PRI Value Facility Code Severity Code Severity Level
<10> 1 2 Critical
<11> 1 3 Error
<12> 1 4 Warning
<14> 1 6 Informational

 

Further details on the individual values can be found in the RFC 5424.

For example, a PRI value of <10> indicates user-level messages (Facility Code 1) with critical severity (Severity Code 2). Each PRI value is calculated as (Facility Code * 😎 + Severity Code. For instance, with a PRI value of <12>, we can break it down as follows:

     Facility Code:           1 (user-level)

     Severity Code:         4 (warning)

     Calculation:              (1 * 😎 + 4 = 12

Syslog Filtering and Forwarding

With this new knowledge, we can turn to the next topic: Syslog Filtering and Forwarding. How to filter Syslog messages in Veeam Backup & Replication is a frequently asked question. Syslog filtering helps reduce log volume by storing or forwarding only relevant messages based on severity, source, or content. This optimizes storage consumption and bandwidth by preventing unnecessary or low-priority logs from being sent to a central monitoring system.

Using PRI Values in Syslog Forwarding

The PRI value allows us to filter Syslog messages based on their severity. In this sample setup, I use rsyslog in a Docker container to filter messages by severity and forward only selected ones to a remote server. The container is configured to listen on a specific TCP port, filter messages with warning (4) severity or higher, and forward them to the designated server over TCP. For detailed setup instructions, please refer to the documentation on GitHub.

In Veeam Backup & Replication, we must then specify the IP address and the destination port of the system on which the Docker container is running to which the Syslog messages will be sent.

Summary and Next Steps

The PRI value, Syslog filtering, and forwarding will help configure a more efficient logging system. This example setup reduces unnecessary protocol traffic and ensures only critical messages reach their destination. To further develop this setup, you should refine the Docker configuration according to your needs, e.g., by adjusting the filter rules or planning for scaling as your logging requirements increase. A fine-tuning of the rsyslog will be included in one of the upcoming updates to the configuration file.

Please note that this sample setup uses a Docker container for rsyslog to simplify administration and offer advantages such as portability, isolation, or scalability. The exact configuration can also be used directly on a Linux server with rsyslog configured. Also worth mentioning: Adjust the firewall rules.

Happy filtering!
Steve Heart

This is a very interesting concept and would alleviate traffic and log congestion for sure.  Something I will look at for our logging since we send to a syslog server and have started using the Splunk App too.


This is a very interesting concept and would alleviate traffic and log congestion for sure.  Something I will look at for our logging since we send to a syslog server and have started using the Splunk App too.

Yeah, worked well in my Splunk lab. As mentioned, I’ll do some fine-tuning based on some experiences in the past.


While we have yet to implement syslogging in our env we are going to within the next yr so something I will keep in mind. Thanks Steve. 


Filtering syslog events is now available: See here!

A script to manage this is on my bucket list 😉 Stay tuned….


Filtering syslog events is now available: See here!

A script to manage this is on my bucket list 😉 Stay tuned….

Very nice feature they added.  I will let me security team know about this but the Splunk app is still the bomb. 😂


I read that in the ‘What’s New’ document. Nice add!


Comment