Getting Started with Syslog-ng

Getting Started with Syslog-ngAll system administrators need to keep a close eye on what is happening within their system, as well as deploy tools that assist in trouble shooting. One such vital tool that all system administrators rely on heavily is the system’s logging utility. Among the most advanced and most popular of these loggers is syslog-ng, which provides features to include message filtering based on level and content, remote logging, uses TCP for transport, can act as a logging server, is able to handle logs from syslogd, and comes with a flexible configuratio n. You can think syslog-ng as having the best features of syslogd and metalog, plus a nice advanced configuration.

Giving the popularity of syslog-ng, it is quite possible that it is already the default logger on your system. If not, it should be easy to install though your package manager. All syslog-ng’s configuration will be done in the syslog-ng.conf file, which is likely located in the /etc/syslog-ng/ directory. Depending upon your distribution’s defaults, the syslog-ng.conf file may be fairly minimalistic, or perhaps it is fairly complex out of the box (such as is the case with RHEL’s EPEL repository, for instance). So, let’s jump into what all of that stuff in your syslog-ng.conf file means!

Syslog-ng Options

The first notable thing in the syslog-ng.conf file is the “options” section. These global options govern DNS usage, timestamp format, and other general options. Generally speaking, the defaults that come with syslog-ng are probably sufficient. However, they are documented pretty well in the syslog-ng admin guide should you want to make any changes.

System Log Sources

Sources, simply put, receives log messages from a specified source. Again, you should have at least one source specified in your syslog-ng.conf already and generally speaking, you can leave the defaults as is on this part. However, should you wish to make some changes, you will need to use the following format:

source{ source-driver(parameters); source-driver(parameters); ...};

For more information on source drivers, please see the official documentation. Your file may contain one or two (or more) source identifiers, and within those it is common to display three source-drivers: file(), unix-stream(), and internal(). The unix-stream() source-driver opens a specified unix socket and listens for incoming messages. The internal() source-driver receives messages generated by syslog-ng. So, the following would mean that the identifier “src” receives messages from the /dev/log socket, and from syslog-ng:

source src { unix-stream(“/dev/log”); internal(); };

At times, kernel messages may be included in a different source. The kernel sends messages to /proc/kmsg. So, to create a source that reads messages from that file, we would include the following:

source kernsrc { file(“/proc/kmsg” ); };

Please note that these two are often included in one source, such as:

source src {
 unix-stream("/dev/log" max-connections(256));

This is by no means incorrect, but would simply require a different source be specified later on in the configuration.

System Log Destinations

This is where we specify the destination for our system logs, or rather, which files (within /var/log usually) we want each log to go. The syntax is as follows:

destination{ destination-driver(parameters);
destination-driver(parameters); ...); };

Most of the time, you will probably be logging to a file, but syslog-ng gives you the option of using a different destinatino-drivers, such as pipe, unix socket, TCP-UDP ports, and others. So, a basic kernel log might look like this:

destination kern { file(“/var/log/kern.log”); };

You can also send messages to the terminal of a specific user, providing the user is logged in. For example, let’s say we went to send console messages to root:

destination console { usertty(“root”); };

System Log Paths

This is the part of the configuration file that ties everything else together. The previously defined sources, and destinations are all incorporated into a log statement. The format for the log statement is:

log {
 source(s1); source(s2); ...
 optional_element(filter1|parser1|rewrite1); optional_element(filter2|parser2|rewrite2);...
 destination(d1); destination(d2); ...
 flags(flag1[, flag2...]);

So, a standard log statement for all messages might look something like this:

log { source(src); destination(messages); };

Sample syslog-ng.conf

Now, let’s put it all together have a look at a complete sample syslog-ng.conf. This would be quite suitable for a simple server or a desktop:

options {

source src {
 unix-stream("/dev/log" max-connections(256));
destination messages { file("/var/log/messages"); };
destination console_all { file("/dev/tty12"); };
log { source(src); destination(messages); };
log { source(src); destination(console_all); };

Well, that should get you started with syslog-ng. You can now specify what you are logging (source statements), define where they go (destination statements), and finally tell syslog-ng to actually create a log (log statements). With that, you should be able to jump in and start customizing your own syslog-ng setup. However, that is just the tip of the ice burg. Next, take a look at How to Filter Logs with Syslog-ng.