Agent installation and data collection are separate stages
Azure Monitor Agent needs an applicable data collection configuration that defines what to collect and where to send it. A successfully installed extension does not prove that the intended Windows events, Linux syslog or performance records reach the expected destination.
A data collection rule, or DCR, describes that collection contract, and its association connects eligible resources to the rule. This guide traces one VM's telemetry path. It does not assume that all destinations or operating-system sources produce the same tables or heartbeat behavior.
Setup: record the full collection path
Identify the VM or supported managed machine, operating system, agent version, managed identity, DCR association and destination. Confirm that the DCR includes the intended source, filter and stream. Record the destination workspace's resource identity rather than relying on a similar display name.
For an appropriate Log Analytics destination, an illustrative read-only query is:
Heartbeat
| where TimeGenerated > ago(30m)
| summarize LastSeen=max(TimeGenerated) by _ResourceId
Restrict the query to the approved resource scope during an incident. A heartbeat is useful for an applicable collection path, but it is not evidence that every selected source is arriving. Some destination configurations need different verification, as the official troubleshooting procedure explains.
Illustrative incident: the rule targets the wrong fleet
In this illustrative example, an agent is healthy on a new VM, but the DCR association still applies only to the earlier pilot fleet. Reinstalling the extension does not add the missing relationship. The intended workspace remains empty for the expected performance records.
The team verifies the actual association and DCR data-source selection, then applies the reviewed association for the new VM. It waits for fresh collection evidence and checks the specific destination table. A green extension status was only one intermediate milestone.
Troubleshooting: compare agent, rule and received records
| Observation | Evidence | Boundary |
|---|---|---|
| No applicable heartbeat or agent activity | Service status and agent diagnostics | Local operation and control-plane connectivity |
| Agent works but intended source is absent | DCR association and source filters | Is this machine enrolled in the correct rule? |
| One source arrives but another does not | Source configuration and expected table | Collection selection rather than total agent failure |
| Data appears in another workspace | Actual destination resource identity | Routing configuration |
Use the Windows or Linux troubleshooting procedure for the installed platform. A syslog facility filter and a Windows event selection do not have interchangeable meanings. Also distinguish a workspace query looking at the wrong time range from a genuine gap in new ingestion.
Correct the smallest configuration disagreement
Repair the association, source selection, destination or evidenced identity/network issue. Confirm which configuration the active agent received before treating a local file edit as effective. Avoid deploying overlapping collection rules without reviewing duplicate-data and cost implications.
Use a pilot machine and a controlled source event where appropriate. Define data retention and access ownership because collected events can contain operational or personal information. A collector rollout should have a documented exit criterion and a rollback that does not unexpectedly remove other required monitoring.
Verification, alerting and SOP
Verify fresh records for the exact resource, source and destination. Compare an approved local source observation with the received record and its timestamp. Observe enough collection cycles to distinguish delayed arrival from a recurring blind spot.
An internal SLO can describe telemetry freshness for enrolled machines; it is distinct from an application availability SLA. The SOP should record DCR and association ownership, OS-specific checks, expected tables, destination, identity, collection costs, retention and the evidence required before extending the rule to the fleet. Alert on missing collection separately from the guest workload's own health.
See Clouvenix observability monitoring for a reviewed implementation and operational handover.
Technical reference
Microsoft DCR collection setup and verification, Microsoft AMA Windows troubleshooting, Microsoft AMA Linux troubleshooting. Reviewed 19 October 2026; use documentation for the installed product and release.