{"id":4564,"date":"2019-07-19T11:29:19","date_gmt":"2019-07-19T09:29:19","guid":{"rendered":"http:\/\/contoso.se\/blog\/?p=4564"},"modified":"2019-07-19T11:31:37","modified_gmt":"2019-07-19T09:31:37","slug":"monitoring-windows-services-with-azure-monitor","status":"publish","type":"post","link":"http:\/\/contoso.se\/blog\/?p=4564","title":{"rendered":"Monitoring Windows services with Azure Monitor"},"content":{"rendered":"\n

Another question we are asked regularly is\nhow to use the Azure Monitor tools to create visibility on Windows service\nhealth. One of the best options for monitoring of services across Windows and\nLinux leverages off the Change\nTracking solution<\/a> in Azure Automation.<\/p>\n\n\n\n

The solution can track changes on both Windows and Linux. On Windows, it supports tracking changes on files, registry keys, services, and installed software. On Linux, it tracks changes to files, software, and daemons. There are a couple of ways to onboard the solution, from a virtual machine, Automation account, or an Azure Automation runbook. Read more about Change tracking and how to onboard at Microsoft Docs<\/a>.<\/a><\/p>\n\n\n\n

This blog post will focus on monitoring of a Window service, but the\nconcept works the same for Linux daemons. <\/p>\n\n\n\n

Changes to Windows Services are collected by default every 30 minutes but can be configured to be collected down to every 10 seconds. It is important that the agent only track changes, not the current state. If there is no change, then there is no data sent to Log Analytics and Azure Automation. Collecting only changes optimizes the performance of the agent. <\/p>\n\n\n\n

\"\"<\/a><\/figure><\/div>\n\n\n\n

Query collected data<\/strong><\/p>\n\n\n\n

To list the latest collected data, we can\nrun the following query. Note that we use \u00e2\u20ac\u0153let\u00e2\u20ac\u009d to set offset between UTC\n(default time zone in Log Analytics) and our current time zones. An important\nthing to remember is what we said earlier; only changes are reported. In the\nexample below, we can see that at 2019-07-15 the service changed state to\nrunning. But after this record, we have no information. If the VM suddenly\ncrashes, there is a risk no \u00e2\u20ac\u0153Stopped\u00e2\u20ac\u009d event will be reported, and from a logging\nperspective, it will look like the service is running. <\/p>\n\n\n\n

It is therefore important to monitoring\neverything from a different point of views, for example, in this example also\nmonitor the heartbeat from the VM. <\/p>\n\n\n\n

let utcoffset = 2h; \/\/ difference between local time zone and UTC
ConfigurationData
| where ConfigDataType == \"WindowsServices\"
| where SvcDisplayName == \"Print Spooler\"
| extend localTimestamp = TimeGenerated + utcoffset
| project localTimestamp, Computer, SvcDisplayName, SvcState
| order by localTimestamp desc
| summarize arg_max(localTimestamp, *) by SvcDisplayName<\/code><\/p>\n\n\n\n

\"\"<\/a><\/figure><\/div>\n\n\n\n

Configure alert on service changes<\/strong><\/p>\n\n\n\n

As with other collected data, it is possible to configure an alert rule based on service changes. Below is a query that can be used to alert if the Print Spooler service is stopped. For more steps how to configure the alert, see Microsoft Docs<\/a>. <\/p>\n\n\n\n

ConfigurationChange
| where ConfigChangeType == \"WindowsServices\" and SvcDisplayName == \"Print Spooler\" and SvcState == \"Stopped\"<\/code><\/p>\n\n\n\n

\"\"<\/a><\/figure><\/div>\n\n\n\n

You may be tempted to use a query to look\nfor Event 7036 in the Application log instead, but there are a few reasons why\nwe would recommend you use the ConfigurationChange data instead:<\/p>\n\n\n\n