As you know OMS can receive syslog messages from its Linux agents. Well this is nothing special anymore, but there might be use cases where you cannot install a Linux agent or you might have some network devices which need to send syslog messages to OMS because you want to do some deep inspection of the data. How would you handle such situation? Well, one way would be to configure a centralized syslog server. This means you “promote” a Linux server as syslog server and this will be the “target” node for the other devices / systems. After that, configure the surrounding systems to “shoot” their events to the syslog server. I will show you how to do that in this demo.
The Linux agents supports e.g. rsyslog or syslog-ng uploading all events from all facilities with a severity of warning or higher. In my example I will use SUSE Enterprise Server 12 which hast rsyslog installed. The default collected event configuration looks like this…
I have installed two Linux systems, SUSE01 and SUSE02. SUSE01 is acting as syslog server, collecting all the events and sending it to OMS. SUSE02 is configured as “client” which will send the events to SUSE01. How did I do that? Let’s see first we will configure SUSE02 (client).
I will not show you how to install Linux nor how to install the OMS Linux agent, because there are enough posts on the internet. Make sure your firewall is also configured for the required ports.
OMS
First you need to prepare your OMS workspace. In OMS you need to configure what facility you would like to get into your workspace. Make sure you configured your workspace, where you have your agent connected to, according to your need. If you need help, check this article here. In my case I added user and local7 facility to my workspace and deployed it to my agents…
After that, we are ready to configure SUSE02 (client).
SUSE02
There is only one file you need to configure to send the events to a remote computer.
It is located in /etc/rsyslog.d/remote.conf
Uncomment the line above and set the IP of your syslog server. In this case it is 192.168.32.18 depending on your requirements, it is also possible to send the messages via TCP which is a more reliable way of sending a large amount of events. We are using for demo purposes only UDP port 514.
Notice the format is *.* @192.168.32.18:514
Next save the file and restart the syslog daemon…
service rsyslog restart
Now we are going to configure SUSE01 (syslog server).
SUSE01
Per default the rsyslog daemon is running, we can check running, which process is using the file…
lsof /var/log/messages
SUSE01 has already the OMS agent installed and it is up and running…
service omsagent status
For receiving syslog messages we need to modify the same file as for SUSE02, it is located in /etc/rsyslog.d/remote.conf. There we need to uncomment just few lines as well. The first lines loads the module and the second line defines the port listing on…
Next save the file and restart the syslog daemon…
service rsyslog restart
Testing
Now we are ready to fire some test events. On SUSE02 we run a test command….
logger –p “user.warning” “I am so cool”
Start monitoring the syslog on SUSE01 by running the command…
tail –f /var/log/messages
and immediately the event is written from SUSE02 to SUSE01 log…
In OMS we run the following query…
Type=Syslog
…and the result is immediately visible…
This is one way how to get syslog data from all sorts of devices into OMS. Cool!
Thanks for the helpful guide!
For the record, if anyone comes across this article, this is an excellent method for syslog forwarding from multiple, disparate systems to a central system with the Log Analytics (OMS) agent installed. You can’t install the agent on network switches, appliances, etc., so rethink the approach: Send syslog to a server that does have it installed. This guide will point you in the right direction.