Actions

Tags

Peter Czanik
7 Feb 2023
Syslog-ng 101, part 6: Destinations and log path

This is the sixth part of my syslog-ng tutorial. Last time, we learned about syslog-ng source definitions and how to check the syslog-ng version. Today, we learn about syslog-ng destinations and the log path. At the end of the session, we will also perform a quick syntax check.

You can watch the video or read the text below.

Destination definition

A destination definition is a collection of one or more destination drivers. It consists of two parts. It starts with the word “destination”, followed by an identifier for the destination which you will use later to refer to the given destination. After that, it lists the destination drivers with their parameters. Here is how its syntax looks like:

destination <identifier> {
  destination-driver(parameters);
  destination-driver(parameters);
  ...
};

And here is a simple file destination:

destination d_file {
  file("/var/log/syslog");
};

Destination drivers

You have already seen the file() destination, but there are many more destination drivers available in syslog-ng. Some of the more common destination drivers are the following:

  • file(): Writes log messages to a file.

  • pipe(), unix-stream() and unix-dgram(): Writes log messages to a pipe or socket.

  • network: Sends legacy (RFC 3164) messages over the network.

  • syslog(): Sends new (RFC 5424) syslog messages over the network.

  • usertty(): Writes to the terminal of the logged in user. Make sure to use this carefully, as it can slow down syslog-ng considerably!

  • program(): Writes to a program’s standard input.

  • http(): Sends log messages to HTTP, like Elasticsearch, Slack, Sumologic and others.

  • python(): Allows you to write your own destination driver in Python.

For the complete list, see the syslog-ng documentation.

Further elements

We have already seen the most basic syslog-ng configuration elements: sources and destinations. So let me show you now some additional elements. We will learn more about these in later tutorials.

  • Options: Allows you to set the global behavior of syslog-ng. Many of these settings can be overridden in later parts of the configuration. For example, you do not have to configure each destination separately – instead, you can set a common value in Options and override it only at the destinations necessary.

  • Macro: Macros are elements of a parsed log message. They can be used to reconstruct messages.

  • Template: Templates are user-defined expressions for reformatting (restructuring) log messages from macros and name-value pairs. For example, adding time zone information or changing to JSON formatting.

  • Filter: Filters are expressions for selecting (filtering) messages.

  • Parser: Parsers separate a message into smaller parts with a separator. The resulting name-value pairs can be used in templates.

  • Rewrite: A sed-like tool that modifies part of the message. This is not meant for falsifying messages of course, but rather for use cases like anonymization to meet various compliance requirements.

The log path

The log path connects the various building blocks of syslog-ng, and thus defines the route of incoming log messages. It can contain sources, destinations, filters, flags and other objects. It refers to the various building blocks by their name (identifier).

log {
  source(s_id1); source (s_id2);...
  filter(f_id1); filter(f_id2);...
  destination(d_id1); destination(d_id2);...
  flags(flag1[,flag2...]);
};

Here you can see a log path, which simply connects a source to a destination, without any further processing:

log {
  source(s_id1);
  destination(d_id1);
};

syslog-ng.conf: minimal

Here you can see a minimal syslog-ng configuration. It contains just a version declaration, a source, a destination, and a log path that connects the source with the destination:

@version:3.38
source s_sys { system(); internal();};
destination d_mesg { file("/var/log/messages"); };
log { source(s_sys); destination(d_mesg); };

syslog-ng.conf: most typical components

The next configuration is still quite simple, but already includes many of the typical configuration elements. We have seen int previously and learned about most of its elements. So the only configuration element we have not yet talked about is the filter.

@version:3.19
@include "scl.conf"

# this is a comment :)

options {flush_lines (0); keep_hostname (yes);};

source s_sys { system(); internal();};
destination d_mesg { file("/var/log/messages"); };
filter f_default { level(info..emerg) and not (facility(mail)); };

log { source(s_sys); filter(f_default); destination(d_mesg); };

Syntax check

Before finishing this part of my syslog-ng tutorial, I want to introduce you to a syslog-ng command line option. Using -s you can check if your syslog-ng configuration is syntactically correct. As such, it can only detect syntax problems but not typos, which means your syslog-ng configuration can still blow up on start if you, for example, misspelled a source name. Still, as a rule of thumb, no output for -s means no problem.

Save one of the example configurations, then check how it works by combining -s with -f (the configuration file name):

QDNDV8D3:~ # syslog-ng -s -f /etc/syslog-ng/first.conf
QDNDV8D3:~ #

In a later part, we will check how you can use the -s option during a syslog-ng version upgrade.

If you have any questions or comments, leave a comment on YouTube or reach out to me on Twitter / Mastodon.

-

If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.

Related Content