Pot Of Syslog-NG Tricks Version 3

Retaining the original hostname of the origin of syslog messages through a Syslog-NG relay

In some environments, syslog messages are concentrated and relayed through an intermediate syslog server.  One of the big deficiencies of the stock syslogd that comes with many Linux/UNIX operating systems is that they don’t provide the ability to keep the hostname or IP address of the original sender of the syslog message as it is transmitted through the syslog relay server.  Syslog-NG provides an option that, when used on the relay server, retains the host name of the originating system.  A basic relay syslog-ng.conf file might look like this:

source s_net { udp(); };
destination d_net { udp(“”); };
log { source(s_net); destination (d_net); };

Simply adding the keep-hostname(); statement to the source definition tells syslog-ng to retain the original host’s name in the syslog message as it is relayed through.  The resulting config file would look like this:

source s_net { udp(keep-hostname();); };
destination d_net { udp(“”); };
log { source(s_net); destination (d_net); };

And that’s all there is to it.

Changing the Facility or Priority of a Syslog Message

From time to time, you may have a unique need to change the facility or priority of a syslog message.  Syslog-NG doesn’t currently support rewriting the “header” parts of a syslog message where the Priority is stored.  However, a clever post on the syslog-ng forums points out that this can effectively be done using templates.   The template command essentially lets us build a syslog message from the ground up.  Rather than using the priority that syslog-NG knows about, we can use our own in a template, like this:

destination d_file {
template(“<166>$DATE $HOST $MSGHDR$MSG\n”; template_escape(no))); };

This will replace the priority on ALL syslog messages sent out through this destination to local4.info (166).  To calculate the priority (the number inside the <>), follow this formula:

(numeric value of facility) * 8 + (numeric value of severity)

The numeric values of the various facilities and severities can be found in RFC3164.

Note: syslog-ng 3.1 introduced the ability to rewrite parts of syslog messages more simply, however, the facility, severity and date are not able to be rewritten using that new functionality.  The method above can be used to rewrite any of those fields.

Importing Logs From Another Log File

Syslog is a tremendously flexible system.  Unfortunately, not all applications support sending their logs out via syslog.  Syslog-NG provides the ability to read in general log files, so long as they are text based logs.

source s_file {

destination d_messages{

log {

This configuration will read logs as they are written to the file /var/log/app.log and write them out to /var/log/messages.  Once the logs have been pulled in, they can be reformatted using the template functionality, sent to a remote host, or any things that can be done with a normal syslog message.

See my new post on importing logs from text files into syslog-ng.