Sending Messages to a Remote Syslog Server

In this recipe, we forward messages from one system to another one. This is used in a number of cases:
the local system does not store any messages (e.g. has not sufficient space to do so)
there is a (e.g. legal) requirement to consolidate all logs on a single system
the server may run some advanced alerting rules, and needs to have a full picture or network activity to work well

In our case, we forward all messages to the remote system. Note that by applying different filters, you may only forward select entries to the remote system. Also note that you can include as many forwarding actions as you like. For example, if you need to have a backup central server, you can simply forward to both of them, using two different forwarding lines.

To learn how to configure the remote server, see recipe Receiving Messages from a Remote System.

Config Statements

*.*   @@192.0.2.1:10514
# if you need to forward to other systems as well, just
# add additional config lines:
*.*   @@other-server.example.net:10514
# 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

Things to think about

You need to select the protocol best suitable for your use case. If in doubt, TCP is a decent choice. This recipe uses TCP for that reason.

TCP forwarding is a build-in capablity and always present. As such, no plugin needs to be loaded. The target can be specified by DNS name or IP address. Use IP addresses for most robust operations. If you use a DNS name and name resolution fails, forwarding may be disabled for some time. DNS resolution typically fails on the DNS server itself during system startup.

In this example, we forward to port 10514. We could as well remove the (“:10514”) part from the configuration, which would result in the default port being used. However, you need to specify the port address on the server in any case. So it is strongly advised to use an explicit port number to make sure that client and server configuration match each other (if they used different ports, the message transfer would not work.

Tags: , ,

5 Responses to “Sending Messages to a Remote Syslog Server”

  1. [...] Using a different log Format for all Files Sending Messages to a Remote Syslog Server [...]

  2. [...] (or may not) process and store messages locally. If they do, doesn’t matter here. See recipe Sending Messages to a Remote Syslog Server for how to configure the [...]

  3. popo008 says:

    the blog is very useful.I agree with the Method of configuring a remote server wha you said in the article.TCP really is a good agreement.TCP forwarding is a build-in capablity and always present.It is easy to use.thanks for sharing the article.

  4. bobo008 says:

    great blog.thanks for tell us how to configure the remote server.the Config Statements is really useful and TCP is TCP is a decent choice.
    thanks for sharing the article,through the article i learned a lot.

  5. KB says:

    FYI, the “This recipe uses TCP for that reason.” is the double @ in “*.* @@192.0.2.1:10514″

    To use UDP use only one single @. For eample: “*.* @192.0.2.1:10514″

Leave a Reply