OMS Log Analytics Forwarder (aka OMS Gateway) Preview
Over the last few days, I had the privilege to review and test a new component of the OMS family called “OMS Log Analytics Forwarder”. Since this component has now been released for public preview, I’d like to dedicate this post to my experience with OMS Log Analytics Forwarder so far.
Initial Configuration
First of all, you can download the bits and documentation from Microsoft Download site here: https://www.microsoft.com/en-us/download/details.aspx?id=51603&WT.mc
In my lab, I have created a new VM running Windows Server 2016 TP4 Server Core. I firstly installed the OMS Direct MMA agent, then the OMS Log Analytics Forwarder using command:
msiexec /i “Microsoft OMS Log Analytics Forwarder.msi”
Once installed, you will see the following components on the VM:
- “Microsoft OMS Log Analytics Forwarder” service
- OMS Log Analytics Forwarder Log
- Various performance counters:
Since I already have OMS MMA agent installed and this gateway box is directly connected to one of my OMS workspace, I have configured my OMS workspace to collect these OMS Log Analytics Forwarder counters
and I also configured my OMS workspace to collect the OMS Log Analytics Forwarder Log in the Windows Event log section:
The Active Client Connection counter represents the number of TCP connections clients established to the OMS Log Analytics Forwarder service. This is not a true representation of number of active clients connected to the forwarder.
The Connected Client counter represent the number of clients connected (both Windows and Linux). However, if I stop the MMA agent on an agent connected to this forwarder, the counter value will not decrease straightaway. This is because in this release, the counter only resets once a day. So you may need to wait for up to 24 hours before you see the value decreases.
Agent Configuration
Now that the OMS Log Analytics Forwarder component has been properly installed, I started reconfiguring some existing agents to go through this forwarder (gateway) machine.
On the Direct-Attached Windows agent, I simply added it under the Proxy Settings tab:
On the Linux agent, we can reconfigure the agent to use the proxy server using the following command (assuming the latest version of the OMS agent is installed):
sudo sh ./omsagent-1.1.0-28.universal.x86.sh –upgrade -p http://
This is documented on here: https://github.com/Microsoft/OMS-Agent-for-Linux/blob/master/docs/OMS-Agent-for-Linux.md#configuring-the-agent-for-use-with-an-http-proxy-server
Additional Configuration for Linux Agents
During my testing, the Windows agents started communicating through the gateway straightaway. This can be verified by looking for Event ID 103 in the OMS Log Analytics Forwarder Log:
and followed by Event ID 107 indicating the connection has been successful:
However, with the Linux agent, I get an error event (Event ID 105) right after Event ID 103:
If you pay close attention to the Event ID 103 events for both Windows and Linux machines, you may notice they are trying to connect to different servers. The Windows machine is trying to connect to xxxxxx.oms.opinsights.azure.com:443 whereas Linux machine is trying to connect to scus-agentservice-prod-1.azure-automation.net
To fix this issue for Linux machine, please go to the server where OMS Log Analytics Forwarder component is installed, open “C:\Program Files\Microsoft OMS Log Analytics Forwarder\allowedlist_server.txt”, and add “scus-agentservice-prod-1.azure-automation.net” to this text file.
After I saved the file and restarted the OMS Log Analytics Forwarder service, the Linux agent started communicating through this forwarder server – I verified by examining a NRT perf counter for Linux as you can see from the screenshot below, the data started coming in after I made the change:
I am pretty sure Microsoft will fix this issue in the future (since we are still at the preview stage).
Additional Information
Nini Ikhena, a program manager from the OMS product team has posted an excellent post on OMS blog: https://blogs.technet.microsoft.com/msoms/2016/03/17/oms-log-analytics-forwarder/
My friend and fellow CDM MVP Daniele Grandini has also posted an excellent in-depth post few minutes ago (well, Daniele beat me this time): https://nocentdocent.wordpress.com/2016/03/17/msoms-gateway-server-preview/
I strongly recommend you to go and read the above mentioned 2 blog posts as they covered some aspect that I didn’t cover in this blog post.
lastly, if you have any suggestions or issues, please feel free to provide feedback via UserVoice: https://feedback.azure.com/forums/267889-azure-operational-insights
Leave a comment