A platform metric is not proof that resource logs are collected
An Azure resource can expose platform metrics while its resource logs are not routed to the workspace an operator expects. Resource-log collection needs the relevant diagnostic configuration. Different services also publish different categories, so a copied setting can be incomplete or inappropriate for another resource type.
This guide establishes a resource-to-destination contract. It is separate from an Azure Monitor Agent DCR used for guest collection. Identify which collection path applies before reinstalling an agent or modifying an unrelated workspace rule.
Setup: choose a resource category and destination intentionally
Record the exact resource identity, supported categories, destination workspace or storage path and expected table model. Identify the operation that generates the log category you want to observe. Review retention, reader access and likely ingestion volume with the data owner.
A collection worksheet can contain:
Resource and supported log category:
Diagnostic-setting identity:
Destination resource identity:
Expected table and schema:
Approved event-generation test:
Create the supported setting on the relevant resource or subresource. Some services expose categories at a more specific resource level. The existence of a setting on a parent resource does not automatically establish collection from every child service.
Illustrative incident: the query targets the wrong table model
In this fictional scenario, a team enables diagnostics for a new resource and queries a table used by an older deployment. Fresh records are routed according to the new setting's supported destination model, so the old query appears empty.
The responder compares resource identity, selected categories and the actual destination schema. It generates an approved new event and looks in the correct table over a suitable window. It does not repeatedly toggle collection merely because a familiar table is empty.
Troubleshooting: follow the resource event into its destination
| Observation | Evidence | Boundary |
|---|---|---|
| Metrics exist but no resource logs appear | Diagnostic categories and setting | Are logs actually enabled for this resource? |
| Setting exists but source is quiet | Approved operation and category definition | Was a relevant fresh event generated? |
| Destination table does not yet exist | First-record delivery and schema model | Has any eligible record reached this destination? |
| Records arrive elsewhere | Full destination identity and setting history | Is the investigator querying the intended resource? |
Allow for the documented service and destination latency. A newly enabled path should be tested with new eligible events, not assumed to reconstruct an earlier uncollected incident. Also review workspace collection constraints when records stop after a previously healthy period.
Correct collection without uncontrolled duplication
Repair the evidenced category, destination or scope mismatch. Compare all applicable settings before adding another route, because duplicate collection can increase cost and confuse analysis. Confirm that policy-driven configuration will preserve rather than overwrite the intended setup.
Use a pilot and an explicit acceptance check before extending collection across a subscription. Retain only the categories needed for the operational and security purpose, with reviewed access. Resource logs may contain identifiers or other data that should not be available to every application user.
Verification, alerting and SOP
Generate an approved event, find its fresh record in the expected table and verify the originating resource identity. Confirm retention and query access separately. Test the query used by the intended alert or dashboard rather than relying only on a generic workspace search.
An internal SLO can define supported log-path freshness and enrollment coverage; it does not promise transactional lossless logging or replace an application SLA. The SOP should record categories, subresource scope, destination schema, expected latency, costs, access owner, change control and the fallback evidence available during a collection gap.
See Clouvenix observability monitoring for a reviewed implementation and operational handover.
Technical reference
Microsoft Azure resource logs, Microsoft resource-log collection tutorial, Microsoft diagnostic-setting behavior. Reviewed 19 October 2026; use documentation for the installed product and release.