Monitor Windows Services for Azure VM

Question

Hello Stan,

I'm trying to check the status of windows services on Azure VM and whether it's running or Stopped using Log analytics Workspace. I customize below KQL Query for the same. Windows Event logs are already enabled in Log analytics Workspace. But it shows 0 results for any Time Range.

I wanted to monitor the various services running in an Azure VM. i.e Whenever the service goes down ( but VM is running) an alert must be generated automatically.

Event
| where EventLog == "System" and EventID ==7036 and Source == "Service Control Manager"
| parse kind=relaxed EventData with '<Data Name="param1">' Windows_Service_Name '</Data><Data Name="param2">' Windows_Service_State '</Data>'
| where Windows_Service_Name in ('InvestPro Scheduler Service', 'InvestPro Worker Service')
| sort by TimeGenerated desc
| project Computer, Windows_Service_Name, Windows_Service_State, TimeGenerated

Is the above Query correct? I also tried by setting up the Heartbeat but it return 0 results for any Time Frame

let utcoffset = 2h; // difference between local time zone and UTC
ConfigurationData
| where ConfigDataType == "WindowsServices"
| where SvcDisplayName == "InvestPro Worker (InvestPro Worker)"
| extend localTimestamp = TimeGenerated + utcoffset
| project localTimestamp, Computer, SvcDisplayName, SvcState
| order by localTimestamp desc
| summarize arg_max(localTimestamp, *) by SvcDisplayName

I dont understand whats wrong?

Answer 1

Data collection seems to be the primary issue. Confirm that the VM has the MicrosoftMonitoringAgent extension installed. Logon to the VM and confirm that the agent is configured with the intended workspace ID in the control panel. You might be connected using the AMA agent which needs a DCR rule for event collection.

The query looks fine. You can probably assume 7036 is service control manager with service stopped. You might consider pairing this with the start event 7001. For example, collect 7036 and 7001 for InvestPro and use an arg-max to report the most recent result. Then you could ignore successful service restarts. Also consider that there are other service control manager events for service startup failure and service crashes. The 7036 only reports a clean service stop. You might also miss service failures that occur after a reboot.

Azure Automation change tracking is another option for monitoring service health.