A syslog server represents a central log monitoring point on a network, to which all kinds of devices including Linux or Windows servers, routers, switches or any other hosts can send their logs over the network. By setting up a syslog server, you can filter and consolidate logs from different hosts and devices into a single location, so that you can view and archive important log messages more easily.

On most Linux distributions, rsyslog is the standard syslog daemon that comes pre-installed. Configured in a client/server architecture, rsyslog can play both roles; as a syslog server rsyslog can gather logs from other devices, and as a syslog client, rsyslog can transmit its internal logs to a remote syslog server.

When logs are collected with syslog, three important things must be taken into consideration:

• Facility level: what type of processes to monitor
• Severity (priority) level: what type of log messages to collect
• Destination: where to send or record log messages

Let’s take a look at how the configuration is defined in more detail.

The facility levels define a way to categorize internal system processes. Some of the common standard facilities in Linux are:

• auth: messages related to authentication (login)
• cron: messages related to scheduled processes or applications
• daemon: messages related to daemons (internal servers)
• kernel: messages related to the kernel
• mail: messages related to internal mail servers
• syslog: messages related to the syslog daemon itself
• lpr: messages related to print servers
• local0 – local7: messages defined by user (local7 is usually used by Cisco and Windows servers)

The severity (priority) levels are standardized, and defined by using standard abbreviation and an assigned number with number 7 being the highest level of all. These levels are:

• emerg: Emergency – 0
• alert: Alerts – 1
• crit: Critical – 2
• err: Errors – 3
• warn: Warnings – 4
• notice: Notification – 5
• info: Information – 6
• debug: Debugging – 7

Finally, the destination statement enforces a syslog client to perform one of three following tasks: (1) save log messages on a local file, (2) route them to a remote syslog server over TCP/UDP, or (3) send them to stdout such as a console.

Installing rsyslog on Remote Server

You will need a copy of rsyslog running on a remote machine which will be recieving the logs from your existing server. It’s best that you have this in a remote location. The reason being that if this server crashes at the same time as your server crashes, you won’t be able to get any logs to troubleshoot any issues.

Assuming that you’re using Ubuntu on the remote machine, you’ll already be running rsyslog. If not, you can install it by following the instructions provided inside the rsyslog website.

Once it’s installed, you will need to make sure that it listens on a port which we will send logs to. The default port is 514 which we’ll keep. You will need to edit the file/etc/rsyslog.conf and uncomment the following lines:

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

After uncommenting the lines, it should look like the following:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Once that’s done, you can now restart the rsyslog service by running the command service rsyslog restart. Your rsyslog instance is now ready to recieve logs from remote hosts.

Setting Up rsyslog on Local Server

This process is extremely easy. All you need to do is tell the existing rsyslog instance on your server to ship logs to your remote server. It’s as easy as creating a file inside the/etc/rsyslog.d folder called “whatever”.conf. Inside that file, all you need to put is

*.*   @remote.server:514
if you are running apps that log separately you will need this template in this file so the logs are forwarded correctly. 

Once you write that file, restart the rsyslog service by running service rsyslog restart and your logs will now start being shipped to your remote server. You can verify that by logging into the remote server and checking the log folder, you’ll find that you now have logs labeled with the hostname of the client server.