The software described in this documentation is either in Extended Support or Sustaining Support. See https://www.oracle.com/us/support/library/enterprise-linux-support-policies-069172.pdf for more information.
Oracle recommends that you upgrade the software described by this documentation as soon as possible.

3.9 Configuring and Using System Logging

The log files contain messages about the system, kernel, services, and applications. For those files that are controlled by the system logging daemon rsyslogd, the main configuration file is /etc/rsyslog.conf, which contains global directives, module directives, and rules.

Global directives specify configuration options that apply to the rsyslogd daemon. All configuration directives must start with a dollar sign ($) and only one directive can be specified on each line. The following example specifies the maximum size of the rsyslog message queue:

$MainMsgQueueSize 50000

The available configuration directives are described in the file /usr/share/doc/rsyslog-version-number/rsyslog_conf_global.html.

The design of rsyslog allows its functionality to be dynamically loaded from modules, which provide configuration directives. To load a module, specify the following directive:

$ModLoad MODULE_name

Modules have the following main categories:

  • Input modules gather messages from various sources. Input module names always start with the im prefix (examples include imfile and imrelp).

  • Filter modules allow rsyslogd to filter messages according to specified rules. The name of a filter module always starts with the fm prefix.

  • Library modules provide functionality for other loadable modules. rsyslogd loads library modules automatically when required. You cannot configure the loading of library modules.

  • Output modules provide the facility to store messages in a database or on other servers in a network, or to encrypt them. Output module names always starts with the om prefix (examples include omsnmp and omrelp).

  • Message modification modules change the content of an rsyslog message.

  • Parser modules allow rsyslogd to parse the message content of messages that it receives. The name of a parser module always starts with the pm prefix.

  • String generator modules generate strings based on the content of messages in cooperation with rsyslog's template feature. The name of a string generator module always starts with the sm prefix.

Input modules receive messages, which pass them to one or more parser modules. A parser module creates a representation of a message in memory, possibly modifying the message, and passes the internal representation to output modules, which can also modify the content before outputting the message.

A description of the available modules can be found at https://www.rsyslog.com/doc/rsyslog_conf_modules.html.

An rsyslog rule consists of a filter part, which selects a subset of messages, and an action part, which specifies what to do with the selected messages. To define a rule in the /etc/rsyslog.conf configuration file, specify a filter and an action on a single line, separated by one or more tabs or spaces.

You can configure rsyslog to filter messages according to various properties. The most commonly used filters are:

  • Expression-based filters, written in the rsyslog scripting language, select messages according to arithmetic, boolean, or string values.

  • Facility/priority-based filters filter messages based on facility and priority values that take the form facility.priority.

  • Property-based filters filter messages by properties such as timegenerated or syslogtag.

The following table lists the available facility keywords for facility/priority-based filters:

Facility Keyword

Description

auth, authpriv

Security, authentication, or authorization messages.

cron

crond messages.

daemon

Messages from system daemons other than crond and rsyslogd.

kern

Kernel messages.

lpr

Line printer subsystem.

mail

Mail system.

news

Network news subsystem.

syslog

Messages generated internally by rsyslogd.

user

User-level messages.

UUCP

UUCP subsystem.

local0 - local7

Local use.

The following table lists the available priority keywords for facility/priority-based filters, in ascending order of importance:

Priority Keyword

Description

debug

Debug-level messages.

info

Informational messages.

notice

Normal but significant condition.

warning

Warning conditions.

err

Error conditions.

crit

Critical conditions.

alert

Immediate action required.

emerg

System is unstable.

All messages of the specified priority and higher are logged according to the specified action. An asterisk (*) wildcard specifies all facilities or priorities. Separate the names of multiple facilities and priorities on a line with commas (,). Separate multiple filters on one line with semicolons (;). Precede a priority with an exclamation mark (!) to select all messages except those with that priority.

The following are examples of facility/priority-based filters.

Select all kernel messages with any priority.

kern.*

Select all mail messages with crit or higher priority.

mail.crit

Select all daemon and kern messages with warning or err priority.

daemon,kern.warning,err

Select all cron messages except those with info or debug priority.

cron.!info,!debug

By default, /etc/rsyslog.conf includes the following rules:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

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

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

You can send the logs to a central log server over TCP by adding the following entry to the forwarding rules section of /etc/rsyslog.conf on each log client:

*.*        @@logsvr:port

where logsvr is the domain name or IP address of the log server and port is the port number (usually, 514).

On the log server, add the following entry to the MODULES section of /etc/rsyslog.conf:

$ModLoad imtcp
$InputTCPServerRun port

where port corresponds to the port number that you set on the log clients.

To manage the rotation and archival of the correct logs, edit /etc/logrotate.d/syslog so that it references each of the log files that are defined in the RULES section of /etc/rsyslog.conf. You can configure how often the logs are rotated and how many past copies of the logs are archived by editing /etc/logrotate.conf.

It is recommended that you configure Logwatch on your log server to monitor the logs for suspicious messages, and disable Logwatch on log clients. However, if you do use Logwatch, disable high precision timestamps by adding the following entry to the GLOBAL DIRECTIVES section of /etc/rsyslog.conf on each system:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

For more information, see the logrotate(8), logwatch(8), rsyslogd(8) and rsyslog.conf(5) manual pages, the HTML documentation in the /usr/share/doc/rsyslog-5.8.10 directory, and the documentation at https://www.rsyslog.com/doc/manual.html.