Rsyslog is a GPL-ed, enhanced syslogd. Among others, it offers support for reliable syslog over TCP, writing to MySQL databases and fully configurable output formats (including great timestamps).

Rsyslogd is an enhanced replacement for previous syslogd, and provides extended filtering, encryption protected relaying of messages, various configuration options, input and output modules, support for transportation via the TCP or UDP protocols. Note that rsyslog is compatible with sysklogd. Hense, it also works with the standard sysog.conf.
A list of log files maintained by rsyslogd can be found in the /etc/rsyslog.conf configuration file. Most log files are located in the /var/log/ directory.
In most cases(default), rsyslogd acts as tradition sysklogd, so let's start with that.

Sections in /etc/rsyslog.conf config file


Rsyslog has a modular design. This enables functionality to be dynamically loaded from modules, which may also be written by any third party. Rsyslog itself offers all non-core functionality as modules.

Exist different classes of loadable modules, Input, Output, Parser, Message Modification, String Generator,  and Library modules.

But traditionally, in /etc/rsyslog.conf, there are two modules loaded by default, both Belong to Input class.

#### MODULES ####
imuxsock: Unix Socket Input
imklog: Kernel Log Input Module


In this section, there are some global configuration setting here, for example:
# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

$template syslogd,"<%PRI%>%TIMESTAMP% %syslogtag%%msg%"


This part is the one you want work with in most of time. You don't need to create an /etc/rsyslog.conf from scratch, perhaps just tweak it a bit for your working environment.

Keep it simple, It's like a filter, when a log message get to rsyslogd, rsyslogd matches its facility, priority(if specified), action(optional), and the log message location.

For example, if you have a program, or script has one logging line like below

logger -p daemon.debug  " daemon started"

In /etc/rsyslogd.conf

You have Facility and priority config like below:

daemon.* /var/log/daemon.log

Then, rsyslogd will log a message in /var/log/daemon.log

Feb 22 23:30:50 fibrevillage user001:  daemon started

This is how rsyslogd works with kernel and user programs

So, In general, each rule includes a selector (what gets logged) and an action (where it will get logged). Each selector includes a facility (what type of message we're talking about) and a priority (how important it is).

More examples(from RHEL):

auth,authpriv.*                 /var/log/secure

Messages of type auth or authpriv (the facility), with any priority, get logged to the file /var/log/secure.

*.*;auth,authpriv.none          /var/log/syslog

Any message type, with any priority, gets logged to /var/log/syslog; except for auth and authpriv messages (which is good since they're already being logged to recure). The special priority none prevents those messages from being logged even though they would have been included in the *.*.

Default Facilities

       The facility argument is used to specify what type of program is
       logging the message.  This lets the configuration file specify that
       messages from different facilities will be handled differently.
       LOG_AUTH       security/authorization messages
LOG_AUTHPRIV security/authorization messages (private) LOG_CRON clock daemon (cron and at) LOG_DAEMON system daemons without separate facility value LOG_FTP ftp daemon LOG_KERN kernel messages (these can't be generated from user processes) LOG_LOCAL0 through LOG_LOCAL7 reserved for local use LOG_LPR line printer subsystem LOG_MAIL mail subsystem LOG_NEWS USENET news subsystem LOG_SYSLOG messages generated internally by syslogd(8) LOG_USER (default) generic user-level messages LOG_UUCP UUCP subsystem

Selector priorities

       This determines the importance of the message.  The levels are, in
       order of decreasing importance:
       LOG_EMERG      system is unusable
       LOG_ALERT      action must be taken immediately
       LOG_CRIT       critical conditions
       LOG_ERR        error conditions
       LOG_WARNING    warning conditions
       LOG_NOTICE     normal, but significant, condition
       LOG_INFO       informational message
       LOG_DEBUG      debug-level message

More examples:

        news.none;mail.none     -/var/log/debug

Note: Normally, specifying a priority like debug means to log anything of that priority or higher. So specifying *.debug would log everything. Adding an equals sign, =debug, means log only debug messages but nothing higher. This rule also excludes auth, authpriv, news and mail messages even if they're debug.


Using above rule, everybody gets emergency messages

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;user.notice;mail.none;authpriv.none;cron.none;local6.none;kern.none;local0.notice        /var/log/messages

The familiar /var/log/messages sure has a complicated rule. It gets anything of priority info, user notice,  unless they're facility mail, authpriv, cron, kernel, local0 and local6.

Note that this overlaps with some of the other rules. So you'll see a lot of the same messages showing up in messages and syslog (which you'll recall got *.*). That was what got me started down this road: all that duplicated logging on our space-limited plug computers.


Templates allow to specify any format a user might want, they must be defined before they are used.

A template consists of a template directive, a name, the actual template text

Here is an example:

$template MyTemplateName,"\7Text %property% some more text\n",

#  where:
#   * $template - tells rsyslog that this line contains a template.
#   * MyTemplateName - template name. All other config lines refer to this name.
#   * "\7Text %property% some more text\n" - templage text

Config daemon, kernel, programs how to log to rsyslogd.

Once you know how rsyslogd works, then it's easy to config application to use syslog. Basically, just specify facility, priority, and what to log, that's it.

For example, in xinetd TCP wrapper, this is logging config in /etc/xinetd.conf

# Define general logging characteristics.
        log_type        = SYSLOG daemon info
        log_on_failure  = HOST
        log_on_success  = PID HOST DURATION EXIT

Is it clear?

See more detail in How to syslog your program output


Comments powered by CComment