A syslog server can be used as a log monitoring center in a network, and all the facilities that can send logs over the network (including Linux or Windows servers, routers, switches, and other hosts) can send logs to it. By setting up a syslog server, logs sent by different facilities/hosts can be filtered and merged into a separate location, making it easier for you to view and retrieve important log messages.
Rsyslog as a standard syslog daemon, it is preinstalled in most Linux distributions. In the configuration of the client/server architecture, Rsyslog also plays two roles: 1. As a syslog server, Rsyslog can collect log information from other facilities; 2. As a syslog client, Rsyslog can transfer its internal log information to a remote syslog server.
Here, we demonstrate how to configure a centralized syslog server with Rsyslog on Linux. Before you go into the details, review the Syslog standard.
Syslog Standard Basics
There are 3 important things to consider when you collect logs through the syslog mechanism:
facility Level : What type of process is being monitored
severity (priority) level : What level of log messages are collected
Target : Where to send or record log messages
Now let's take a deeper look at how the configuration is defined.
The facility hierarchy defines a method for classifying internal system processes, and some of the common facilities in Linux include:
Auth: Authentication-related messages (at logon)
Cron: messages related to process or app scheduling
Daemon: Daemon-related messages (internal server)
Kernel : Kernel-related messages
Mail: internal mail server-related messages
syslog : Messages related to the syslog daemon itself
LPR: Print Service-related messages
LOCAL0-LOCAL7: user-defined messages (LOCAL7 is typically used by Cisco and Windows servers)
The severity (priority) level has a fixed standard abbreviation and a reference value, where the number 7 has the highest level, which includes:
Finally, the target statement causes a syslog client to perform one of the following three tasks:
Save the log message to a local file;
Routing messages to a remote syslog server via TCP/UDP;
Send it to a standard output, such as a console.
In Rsyslog, the configuration of the syslog is structured based on the following pattern.
[Facility-level]. [Severity-level] [Destination]
Configuring Rsyslog in Linux
After we understand the syslog, it is now possible to configure a Linux server as a central syslog server with Rsyslog. In addition, we will see how to configure a Syslog client on a Windows system to send internal logs to that Syslog server.
1th Step: Initializing system requirements
To set up a Linux host as a central log server, we need to create a separate/var partition and allocate enough disk space or create a special LVM volume group. This will allow the Syslog server to assume the potential growth of collecting logs over the accumulated period.
2nd step: Let the rsyslog background process take effect
The Rsyslog daemon comes from the preinstalled modules of the current Linux release, but it is not started by default. In order to enable the Rsyslog daemon to accept external messages, it is necessary to edit its configuration file/etc/rsyslog.conf.
Open the file for editing, find the location of the following two lines, and uncomment it by removing the # character from its beginning.
This allows the Rsysolog daemon to accept log messages on UDP port 514---UDP is a faster than TCP, but does not have TCP-like traffic reliability. So if you need to use a reliable delivery mechanism, you can cancel the comments on the following lines.
It is important to note that TCP and UDP can be simultaneously active to listen for TCP/UDP connections.
3rd step: Create a Log receive template
The next step is to create a template for the remote message and tell the Rsyslog daemon how to log messages received from other client machines.
Use a text editor to open/etc/rsyslog.conf and append the following template before the global Directive block.
$template remotelogs, "/var/log/%hostname%/%programname%.log" *
*.* ? Remotelogs
This template is briefly explained here, $template Remotelogs (where the "remotelogs" string can be any other descriptive name) directive enables the Rsyslog background process to write log messages to a separate local log file under/var/log, The name of the log file is defined based on the host name of the remote log sending machine and the name of the application that generated the log. The second line implies that we apply the Remotelogs template to all incoming logs.
The symbol "& ~" represents a redirection rule that is used to tell the Rsyslog daemon to stop further processing of log messages and not write locally. If the redirection rule is not used, all remote messages are written to the local log file in addition to the log file described above, which means that the log message was actually written two times. Another result of using this rule is that the log messages for the Syslog server itself will only be in a proprietary file named after the hostname of that machine.
If you want, you can also use the following pattern to log messages directly to a specific device or severity level using a new template.
[Facility-level]. [Severity-level]? Remotelogs
Specify all internal user authentication messages for all priority levels as Remotelogs templates:
Specify the message-level logs from all system processes except mail, user authentication, and cron messages as Remotelogs templates:
If we want to write all the messages received from the remote client to a single file named after their IP address, you can use the following template. Here we give the template the name "Iptemplate".
$template iptemplate, "/var/log/%fromhost-ip%.log"
*.* ? Iptemplate
After we have enabled the Rsyslog daemon and edited the configuration file, we need to restart the daemon.
In Debian,ubuntu or Centos/rhel 6:
$ sudo service rsyslog restart
In Fedora or Centos/rhel 7:
$ sudo systemctl restart Rsyslog
We can verify that the Rsyslog daemon is working properly with the netstat command.
$ sudo netstat-tulpn | grep rsyslog
The Rsyslog daemon that works under the UDP listening port will have output similar to the following.
UDP 0 0 0.0.0.0:514 0.0.0.0:* 551/rsyslogd
UDP6 0 0::: 514:::* 551/rsyslogd
If the Rsyslog daemon is set on a TCP connection port, then there should be output similar to the one shown below.
TCP 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 1891/rsyslogd
TCP6 0 0::: 514:::* LISTEN 1891/RSYSLOGD
Send Windows logs to a remote Rsyslog server
To forward log messages for a Windows client to our Rsyslog server, you need a Windows Syslog agent installed. Of course, there are a number of syslog proxies that can be run on windows, where we can use a free software program Datagram syslogagent.
After you download and install the syslog agent, you need to configure it to run as a service. Specifies which protocol to use to send data, as well as the IP address and port of the remote Rsyslog server, and finally specifies the type of event log that should be transferred.
After we have completed all of these configurations, we can start the service and use the command-line tool tail-f in the central Rsyslog server to view the log files.
By creating a central Rsyslog server that collects local and remote hosts, we can better understand what is going on inside these systems and can debug their problems more easily, whether there are any delays or crashes between them.
Free pick up Brother Lian IT Education Original Linux Operations Engineer video/Detailed Linux tutorials, details of the website customer service: http://www.lampbrother.net/linux/
or hooking up with Q2430675018.
Welcome to the Linux Communication Group 478068715
Configuring a syslog server on Linux