Syslog Message Collection for OMS from sources that do not support the agent
On the previous article of the OMS series, we've installed and configured the OMS agent on a linux machine and started collecting syslog messages and performance statistics.
Today, we are going to use that machine to collect syslog messages from other machines, devices or applications that are not supported by the OMS agent. This is a two step process, first we are going to enable the remote syslog collection on the linux machine and then we are going to update the configuration of the agent to support high volume of syslog traffic. Let's dive in!
The syslog server is going to be rsyslog since it came with Ubuntu server and the configuration file is stored at /etc/rsyslog.conf.
To enable the remote collection, the below lines have to be uncommented in the configuration file:
module(load="imudp")
input(type="imudp" port="514")
and
module(load="imtcp")
input(type="imtcp" port="514")
Since we are going to be collecting messages from other machines, we should separate the syslog files. Fortunately, rsyslog provides that ability by adding the following two lines before the global directives section of the configuration file:
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" *
*.* ?RemoteLogs
Your file should look like this:
Since the oms agent on the syslog server is going to process high volume of syslog traffic, we have to tweak the configuration of the agent. First we are going to disable the centralized configuration for the agent by issuing the below command:
If for any reason you have to enable the centralized configuration, you can do it with the following command:
Now open the syslog configuration file for the agent inside the subscription folder (something like /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/syslog.conf) and locate the source item that is of type syslog. Here, you have to comment the line protocol_type udp and uncomment the #protocol_type tcp. This will configure the oms syslog instance to listen on TCP instead of UDP.
Since the agent's syslog (not rsyslog) is now listening on TCP, we have to update rsyslog accordingly. Open the file /etc/rsyslog.d/95-omsagent.conf and add a second "@" in front of any instance of @127.0.0.1:25224
Below is my configuration file:
For changes to take effect, the agent and syslog daemons have to be restarted:
The linux box is now ready to receive syslog messages from other sources and upload them to the OMS workspace. The next step is to configure the clients to send syslog messages to the linux box.
When you're done with the configuration of the clients, a folder should be created for each client in /var/log containing the respective files.
As you can see, I've configured my netscaler and router to send syslog messages to the syslog server.
Back to the OMS workspace, the messages are available under the "Syslog" space and have all the useful properties such as TimeGenerated, Computer, etc.
When implementing the above solution for production systems, you should consider using a separate disk for the log files and also configure the retention period.
Related articles
Introduction to Azure Advanced Analytics
Configuring Log and Performance Counter collection on the OMS Workspace
Install and Configure the OMS Windows Agent
Verify the Agent Connectivity to OMS Workspace
Deploying the OMS Windows Agent using DSC
Querying OMS for Performance Data
Querying OMS for Events
Collecting IIS Log Files
Install and Configure the OMS Linux Agent
Syslog Message Collection for OMS from sources that do not support the agent
Generating Alerts on OMS
Update Management using OMS
Monitoring Active Directory Health using OMS
Assessing Security using OMS
Monitoring Microsoft SQL using OMS
Monitoring Azure Activity Log using OMS
Today, we are going to use that machine to collect syslog messages from other machines, devices or applications that are not supported by the OMS agent. This is a two step process, first we are going to enable the remote syslog collection on the linux machine and then we are going to update the configuration of the agent to support high volume of syslog traffic. Let's dive in!
The syslog server is going to be rsyslog since it came with Ubuntu server and the configuration file is stored at /etc/rsyslog.conf.
To enable the remote collection, the below lines have to be uncommented in the configuration file:
module(load="imudp")
input(type="imudp" port="514")
and
module(load="imtcp")
input(type="imtcp" port="514")
Since we are going to be collecting messages from other machines, we should separate the syslog files. Fortunately, rsyslog provides that ability by adding the following two lines before the global directives section of the configuration file:
$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" *
*.* ?RemoteLogs
Your file should look like this:
Since the oms agent on the syslog server is going to process high volume of syslog traffic, we have to tweak the configuration of the agent. First we are going to disable the centralized configuration for the agent by issuing the below command:
sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable
If for any reason you have to enable the centralized configuration, you can do it with the following command:
sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py -enable
Now open the syslog configuration file for the agent inside the subscription folder (something like /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/syslog.conf) and locate the source item that is of type syslog. Here, you have to comment the line protocol_type udp and uncomment the #protocol_type tcp. This will configure the oms syslog instance to listen on TCP instead of UDP.
Since the agent's syslog (not rsyslog) is now listening on TCP, we have to update rsyslog accordingly. Open the file /etc/rsyslog.d/95-omsagent.conf and add a second "@" in front of any instance of @127.0.0.1:25224
Below is my configuration file:
For changes to take effect, the agent and syslog daemons have to be restarted:
sudo /opt/microsoft/omsagent/bin/service_control restart
sudo service rsyslog restart
The linux box is now ready to receive syslog messages from other sources and upload them to the OMS workspace. The next step is to configure the clients to send syslog messages to the linux box.
When you're done with the configuration of the clients, a folder should be created for each client in /var/log containing the respective files.
As you can see, I've configured my netscaler and router to send syslog messages to the syslog server.
Back to the OMS workspace, the messages are available under the "Syslog" space and have all the useful properties such as TimeGenerated, Computer, etc.
When implementing the above solution for production systems, you should consider using a separate disk for the log files and also configure the retention period.
Related articles
Introduction to Azure Advanced Analytics
Configuring Log and Performance Counter collection on the OMS Workspace
Install and Configure the OMS Windows Agent
Verify the Agent Connectivity to OMS Workspace
Deploying the OMS Windows Agent using DSC
Querying OMS for Performance Data
Querying OMS for Events
Collecting IIS Log Files
Install and Configure the OMS Linux Agent
Syslog Message Collection for OMS from sources that do not support the agent
Generating Alerts on OMS
Update Management using OMS
Monitoring Active Directory Health using OMS
Assessing Security using OMS
Monitoring Microsoft SQL using OMS
Monitoring Azure Activity Log using OMS
