"Linux Gazette...making Linux just a little more fun!"

1. Introduction

One of the most neglected area of Unix is handling system events. Daily checks for system messages is crucial for the security and health conditions of a computer system.

System logs contain much "noise" - messages which have no importance - and on the contrary important events, which should not be lost in the load of messages. With current tools it's difficult to select which messages we are interested in.

A message is sent to different destinations based on the assigned facility/priority pair. There are 12+8 (12 real and 8 local) predefined facilities (mail, news, auth etc.), and 8 different priorities (ranging from alert to debug).

One problem is that there are facilities which are too general (daemon), and these facilities are used by many programs, even if they do not relate each other. It is difficult to find the interesting bits from the enourmous amount of messages.

A second problem is that there are very few programs which allow setting their "facility code" to log under. It's at best a compile time parameter.

So using facilities as a means of filtering is not the best way. For it to be a good solution would require runtime option for all applications, which specifies the log facility to log under, and the ability to create new facilities in syslogd. Neither of these are available, and the first is neither feasible.

One of the design principles of syslog-ng was to make message filtering much more fine-grained. syslog-ng is able to filter messages based on the contents of messages in addition to the priority/facility pair. This way only the messages we are really interested in get to a specific destination. Another design principle was to make logforwarding between firewalled segments easier: long hostname format, which makes it easy to find the originating and chain of forwarding hosts even if a log message traverses several computers. And last principle was a clean and powerful configuration file format.

This article tries to give you an overview on syslog-ng's internals, for more detailed information see http://www.balabit.hu/products/syslog-ng and select the documentation link.

2. Message paths

In syslog-ng a message path (or message route) consist of one or more sources, one or more filtering rules and one or more destinations (sinks). A message is entered to syslog-ng in one of its sources, if that message matches the filtering rules it goes out using one of the destinations.

2.1. Sources

A source is a collection of source drivers, which collect messages using a given method. For instance there's a source driver for AF_UNIX, SOCK_STREAM style sockets, which is used by the Linux syslog() call.

Different platforms use different means of sending log messages to the logging daemon, and to be useful on all operating systems, syslog-ng has support for the most common methods. Tested support exists for Linux, BSDi, experimental support exists for Solaris (as of version 1.1.22)

2.2. Destinations

A destination is a message sink, where log is sent if filtering rules match. Similarly to sources, destinations may include several drivers which define how messages are dispatched.

For instance there's a file driver, which writes messages to the given file, but support exists to send messages to unix, udp and tcp sockets as well.

2.3. Filters

Filters perform log routing inside syslog-ng. You can write a boolean expression using internal functions, which has to evaluate to true for the message to pass.

An expression may contain the operators "and", "or" and "not", and the following functions:

• facility()
• level()
• program()
• host()
• match()

Each of the above functions check the corresponding field of a log message for matching (e.g. program() checks whether the given program sent the message, or not). You can use extended regular expressions for matching.

2.4. Log statements

Now you have sources, destinations and filters. To connect these together you need the log statement:

log { source s1; source s2; ... 
      filter f1; filter f2; ... 
      destination d1; destination d2; ... };

Messages coming from any of the listed sources, and matching against all the listed filters (which effectively ANDs them) are sent to all of the listed destinations.

3. Example configuration

This configuration file shows the possibilities and features of syslog-ng. It receives messages from the network, and also handles local messages. Three distinct output files are used: one for the messages from sendmail, a second for messages coming from host1, and a third for messages coming from host2.

options { long_hostnames(on); sync(0); };

source src { udp 0.0.0.0,514; unix-stream /dev/log; internal; };

filter f_sendmail { program("sendmail"); };
filter f_host1 { host("host1"); };
filter f_host2 { host("host2"); };

destination sendmail { file /var/log/sendmail; };
destination host1 { file /var/log/host1; };
destination host2 { file /var/log/host2; };

log { source src; filter f_sendmail; destination sendmail; };
log { source src; filter f_host1; destination host1; };
log { source src; filter f_host2; destination host2; };

4. References

Syslog-ng is a product of BalaBit Computing, and is distributed under the GPL. If you are interested, please visit http://www.balabit.hu.