Tutorial for SYSLOG with Examples in Red Hat Linux

I have written another article with step by step instructions to redirect specific messages to different a log file from /var/log/messages so that your messages file is not filled up with unwanted eventsSyslog is one of the most important standards used in Linux as it is the key file which helps you determine the different level of logs which are getting generated and stored every second while you are working on your Linux box. Syslog can be taken as "System Log".
The main configuration file for syslog is
For RHEL 5 and older

/etc/syslog.conf

For RHEL 6 and 7

/etc/rsyslog.conf

Benefits of syslog

• Helps analyze the root cause for any trouble or problem caused
• Reduce overall downtime helping to troubleshoot issues faster with all the logs
• Improves incident management by active detection of issues
• Self-determination of incidents along with auto resolution
• Simplified architecture with different level of severity like error,info,warning etc

The syslog.conf file is the main configuration file for the syslogd which logs system messages on *nix Systems.  This file specifies rules for logging. Every rule consists of two fields, a selector field and an action field.  These two fields are separated by one or more spaces or tabs.  The selector field specifies a pattern of facilities and priorities belonging to the specified action.

Selectors

The selector field itself again consists of two parts, a facility and a priority, separated by a period (''.'').  Both parts are case insensitive.
For example

Kern.none, mail.info etc
Here
Kern = Facility
None = severity or priority

Facility

The facility is one of the following keywords: auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security (same as auth), syslog, user, uucp and local0 through local7.  The keyword security should not be used anymore and mark is only for internal use and therefore should not be used in applications.
Anyway, you may want to specify and redirect these messages here.  The facility specifies the subsystem that produced the message, i.e. all mail programs log with the mail facility (LOG_MAIL) if they log using syslog.

Facility Number

Severity Levels

The priority is one of the following keywords, in ascending order: debug, info, notice, warning, warn (same as warning), err, error (same as err), crit, alert, emerg, panic (same as emerg).  The keywords error, warn and panic are deprecated and should not be used anymore. The priority defines the severity of the message

You can specify multiple facilities with the same priority pattern in one statement using the comma ('','') operator.  You may specify as much facilities as you want. Multiple selectors may be specified for a single action using the semicolon ('';'') separator.  Remember that each selector in the selector field is capable to overwrite the preceding ones.  Using this behavior you can exclude some priorities from the pattern.
Examples
Log all the critical events on your Linux machine in a separate log file inside /var/log with a name of critical.log
Append this line inside /etc/syslog.conf

*.=crit            /var/log/critical.log

Log all the kernel related messages in separate log file inside /var/log/firewall.log

# Add a new line
Kern.*       /var/log/firewall.log
# Add a new entry at the end of the below line
# Log anything (except mail) of level info or higher.
# don’t log private authentication messages!
# don’t log kernel related events and messages
*.info;mail.none;authpriv.none;cron.none;kern.none                /var/log/messages

Redirect all the error logs to a remote user root and Deepak on their terminals

# Messages of the priority alert will be directed
# to the operator
#
*.err                      root,deepak

Log all the firewall warning level messages inside /var/log/firewall-warning.log

Kern.warn                                           /var/log/firewall-warning.log

Support for Remote Logging

These modifications provide network support to the syslogd facility.  Network support means that messages can be forwarded from one node running syslogd to another node running syslogd where they will be actually logged to a disk file.
The strategy is to have syslogd listen on a unix domain socket for locally generated log messages.  This behavior will allow syslogd to inter-operate with the syslog found in the standard C library.  At the same time syslogd listens on the standard syslog port for messages forwarded from other hosts.  To have this work  correctly the /etc/services file must have the following entry:

Syslog 514/udp

If this entry is missing syslogd neither can receive remote messages nor send them, because the UDP port can’t be opened.  Instead syslogd will die immediately, blowing out an error message.
For example,
to forward ALL messages to a remote host uses the following syslog.conf entry:

                   # Sample syslogd configuration files to
                   # Messages to a remote host forward all.
*.*            @hostname

To forward all kernel messages to a remote host the configuration file would be as follows:

                   # Sample configuration files to forward all kernels
                   # messages to a remote host.
                   kern.*         @hostname

References
Linux man page for syslogd
syslog wiki