syslog-ng Open Source Edition 3.30 - Administration Guide

internal: Collecting internal messages

All messages generated internally by syslog-ng use this special source. To collect warnings, errors and notices from syslog-ng itself, include this source in one of your source statements.

internal()

The syslog-ng application will issue a warning upon startup if none of the defined log paths reference this driver.

source s_local { internal(); };

The syslog-ng OSE application sends the following message types from the internal() source:

• fatal: Priority value: critical (2), Facility value: syslog (5)

• error: Priority value: error (3), Facility value: syslog (5)

• warning: Priority value: warning (4), Facility value: syslog (5)

• notice: Priority value: notice (5), Facility value: syslog (5)

• info: Priority value: info (6), Facility value: syslog (5)

internal() source options

The internal() driver has the following options:

host-override()

Description: Replaces the ${HOST} part of the message with the parameter string.

log-iw-size()

Description: The size of the initial window, this value is used during flow-control. Its value cannot be lower than 100, unless the dynamic-window-size() option is enabled. For details on flow-control, see Managing incoming and outgoing messages with flow-control.

program-override()

Description: Replaces the ${PROGRAM} part of the message with the parameter string. For example, to mark every message coming from the kernel, include the program-override("kernel") option in the source containing /proc/kmsg.

tags()

Description: Label the messages received from the source with custom tags. Tags must be unique, and enclosed between double quotes. When adding multiple tags, separate them with comma, for example, tags("dmz", "router"). This option is available only in syslog-ng 3.1 and later.

file: Collecting messages from text files

Collects log messages from plain-text files, for example, from the logfiles of an Apache webserver. If you want to use wildcards in the filename, use the wildcard-file() source.

The syslog-ng application notices if a file is renamed or replaced with a new file, so it can correctly follow the file even if logrotation is used. When syslog-ng is restarted, it records the position of the last sent log message in the /opt/syslog-ng/var/syslog-ng.persist file, and continues to send messages from this position after the restart.

The file driver has a single required parameter specifying the file to open. If you want to use wildcards in the filename, use the wildcard-file() source. For the list of available optional parameters, see file() source options.

file("filename");

source s_file {
    file("/var/log/messages");
};

source s_tail {
    file("/var/log/apache/access.log" follow-freq(1) flags(no-parse));
};

Notes on reading kernel messages

Note the following points when reading kernel messages on various platforms.

• The kernel usually sends log messages to a special file (/dev/kmsg on BSDs, /proc/kmsg on Linux). The file() driver reads log messages from such files. The syslog-ng application can periodically check the file for new log messages if the follow-freq() option is set.

• On Linux, the klogd daemon can be used in addition to syslog-ng to read kernel messages and forward them to syslog-ng. klogd used to preprocess kernel messages to resolve symbols and so on, but as this is deprecated by ksymoops there is really no point in running both klogd and syslog-ng in parallel. Also note that running two processes reading /proc/kmsg at the same time might result in dead-locks.

• When using syslog-ng to read messages from the /proc/kmsg file, syslog-ng automatically disables the follow-freq() parameter to avoid blocking the file.

• To read the kernel messages on HP-UX platforms, use the following options in the source statement:

  file("/dev/klog" program-override("kernel") flags(kernel) follow-freq(0));