In my blog post Defining Input Parameters For Policy Definitions in ARM Template I’ve showed you how to use deploy policy definitions with parameters via ARM template. I didn’t described completely on why such workaround is needed but I think now it is good time to explain that as well. The topic is a little bit complex so I hope my explanation will help you understand it.
Yesterday I got the news that I am renewed as Microsoft MVP for another year. It was quite busy and eventful year for me in both personal and work life. I am glad that I still have managed to earn this recognition. This is my 6th MVP award in a row and I am happy that I’ve got it. Congratulations also to all the other MVPs who got awarded!
For quite some time it was clear that the OMS Portal will move completely to Azure and that is good news. We have seen services like Update Management, Azure Security Center (Security & Audit solution is part of it) releasing new functionalities only in Azure Portal. In fact some services that have been part of OMS (OMS is a suite not a product or service) have always been in Azure Portal. Such services are Azure Backup, Site Recovery, Application Insights, etc. Microsoft has documented OMS Portal deprecation but I would like to add some things to the ones documented there:
As you know both OMS Linux and Windows agent send heartbeat events and they are free of charge. The problem is that the interval of these heartbeat events is different for both operating systems. For Windows it is every 1 minute and for Linux is every 5 minutes. I do not know exactly the reason for this decision but I prefer that all my servers report at the same interval. The beautiful thing with the OMS Linux agent that is extendable and configurable. So this blog post will focus on how you can easily change the heartbeat interval on OMS Linux agent to 1 minute.
Monitoring Windows Services States is one of the most common requests that I’ve seen on forums, groups and blog posts. My fellow MVP and OMS expert Stefan Roth wrote a similar blog post titled OMS – Monitor Windows Services / Processes. I would suggest to check it out as well. The approach I will show is somehow already cover in official article that demonstrates custom fields in Log Analytics. The difference is that we now have the new rich Log Analytics search syntax so we do not need custom fields anymore. This approach also is different from Stefan’s as his one covers wider topic with monitoring processes by using performance counters. In this approach we will use windows events which Stefan mentions that is not reliable but he was referring to specific Event Id which I also agree it is not reliable. In the next steps I will use another Event Id that is reliable 100%. The advantage of using windows events for monitoring windows services states are:
- Only windows events are gathered which results in less data uploaded compared to performance data
You do not have to add performance counter for each process, you just need to add only one event log to monitor all services
The services are shown with their actual name that is used in services.msc or Get-Service cmdlet.
We have the actual state of the service when it happened
Some of the disadvantages of this method are:
- Until the service is started or stopped it will take at least 5 minutes until the data appears in Log Analytics