A metric can tell you a virtual machine is struggling; a log can help explain why. Log Analytics brings VM logs and telemetry into a workspace, where you can search across them with Kusto Query Language (KQL). Instead of opening one machine at a time, you can investigate what happened across your environment. section 3.6.2 section 3.7.1
The clues come from different places:
- Activity logs record Azure control-plane actions, such as starting a VM or changing its configuration. Use them to check who did what and when. section 3.7
- Diagnostic and guest logs expose what is happening inside the VM. Depending on what you collect, these include performance counters, application logs, Windows Event Logs, and Linux syslog. section 3.6.2 section 3.7
- Heartbeat signals report whether a VM is still checking in. Missing signals are a clue worth investigating, not an explanation on their own. section 3.6.2 section 3.7.1
First, enable VM diagnostics and send the logs you need to a Log Analytics workspace. In the Azure Portal, open the workspace connected to your VM and select Logs to run KQL queries. You can filter by time, correlate sources, and reuse queries in workbooks—interactive dashboards combining queries, metrics, and visualizations. Once a pattern matters operationally, use it to drive an alert or dashboard. Collecting logs without acting on them is rather like saving every receipt and never checking the bill. section 3.6.2 section 3.7.1
Investigate an unexpected reboot
Suppose an application is sluggish and you suspect its VM restarted overnight. Query the Heartbeat table for each machine’s latest check-in; a gap may point to a reboot. Then look for Windows system events or Linux syslog entries around that time. Cross-check nearby updates, service failures, and Azure Activity Log operations before deciding what caused the interruption. section 3.7.1
Heartbeat | where TimeGenerated > ago(24h) | summarize LastSeen=max(TimeGenerated) by Computer
This KQL query finds each computer’s most recent heartbeat in the past 24 hours—the first clue in the reboot investigation. section 3.7.1
