Azure Monitor Data Collection Rules, commonly called DCRs, define how supported telemetry enters Azure Monitor: what data sources are collected, which streams they produce, which transformations are applied, and where the results are sent. They replace many one-off collection configurations with a centralized resource that can be versioned, associated with workloads, and managed through automation.<\/p>\n
For candidates and operators working around Microsoft AZ-104<\/a>, DCRs are important because monitoring is no longer just \u201cinstall an agent and point it at a workspace.\u201d The design now includes data-source selection, schema, filtering, destination strategy, resource associations, and cost control.<\/p>\n Microsoft describes the DCR process as ETL-like: data is extracted from a source, optionally transformed, and loaded into destinations such as Log Analytics or other supported targets. The benefit is consistency. The risk is that a badly designed rule can collect too much, drop important records, or send the right data to the wrong place at scale.<\/p>\n Begin with operational and security questions, not with every available counter or event log. Ask which signals are needed to detect failure, investigate incidents, prove compliance, and measure service health.<\/p>\n Collecting everything feels safe until ingestion cost rises and analysts cannot find the relevant records. Excess telemetry can also increase retention expense and query noise. A DCR should therefore encode intentional selection rather than blanket collection.<\/p>\n The approach in Azure logging and monitoring design<\/a> applies directly: telemetry is valuable when it supports decisions. The collection layer should reflect those decisions before the data reaches the workspace.<\/p>\n A DCR can define data sources, input streams, data flows, transformations, and destinations depending on the scenario. These elements form a pipeline. A source produces a stream, a data flow routes that stream, a transformation can modify it, and the destination stores or receives the result.<\/p>\n Read the rule as a flow rather than a flat configuration file. When troubleshooting, follow the data from source to destination and verify each mapping. A missing stream reference or mismatched output schema can break collection even when the resource association appears correct.<\/p>\n For direct ingestion scenarios, the incoming application explicitly targets a DCR. For agent-based collection, the DCR normally describes what the Azure Monitor Agent should collect and where it should send it.<\/p>\n Creating a DCR does not automatically make every VM or resource follow it. Data Collection Rule Associations connect supported resources to rules. The relationship can be many-to-many, so a resource may use multiple DCRs and a single DCR may apply to many resources.<\/p>\n That flexibility is useful for separating baseline monitoring from specialized collection. A common pattern is one broadly applied rule for standard operating signals plus a narrower rule for workloads that require additional logs.<\/p>\n It also creates overlap risk. If two DCRs collect the same source and send it to the same destination, duplicate ingestion can occur. Maintain an inventory of associations and treat unexpected duplicates as a configuration defect, not an unavoidable monitoring cost.<\/p>\n DCR transformations use KQL-based logic to filter or reshape incoming data before storage in supported scenarios. Filtering noisy records before ingestion can reduce cost, and removing sensitive fields can limit what is persisted.<\/p>\n Transformations should be simple enough to reason about during incidents. A complex chain that aggressively drops records can make a later investigation impossible. Document what is removed and why, and test changes with representative samples.<\/p>\n This is where Log Analytics workspace architecture<\/a> and DCR design meet. Workspace structure determines where data lives; transformations determine what data reaches it and in what shape.<\/p>\n A DCR can route supported streams to one or more destinations depending on the collection scenario. The destination choice affects data residency, access control, query patterns, retention, and cost.<\/p>\n Avoid creating a separate workspace for every application only because DCRs make routing easy. Likewise, avoid one global workspace when teams require materially different retention, access, or regulatory boundaries. Choose destination architecture deliberately and use DCRs to implement it.<\/p>\n If a data source must be sent to multiple destinations, verify whether the specific stream and scenario support that pattern and whether the extra ingestion is justified. Multi-homing is useful for real requirements, not as a substitute for deciding who owns the data.<\/p>\n For Azure Monitor Agent scenarios, DCRs define what Windows events, performance counters, syslog, text logs, or other supported sources are collected. Treat these rules as infrastructure code.<\/p>\n Use source control, environment promotion, and review. A casual portal change to a shared DCR can alter telemetry for hundreds of machines. The resulting incident may not be obvious until a dashboard goes quiet or costs change.<\/p>\n The operational mindset from Azure Monitor troubleshooting<\/a> helps: when expected data disappears, check the resource, agent, DCR association, rule definition, transformation, and destination rather than assuming the query is wrong.<\/p>\n Transformations and custom ingestion rely on understanding incoming and outgoing schema. If an application changes field names or types, a transformation can begin failing or dropping data.<\/p>\n Version application telemetry contracts where possible. Test DCR transformations against new schemas before deployment and monitor ingestion errors after changes. For custom tables, confirm the output stream matches the target table\u2019s expected structure.<\/p>\n Schema drift is especially dangerous because it can produce partial monitoring failure. Some records continue to arrive, giving a false sense that collection is healthy while the most important fields have stopped populating.<\/p>\n When a source changes fields or types, validate both the transformation and every downstream query that depends on the affected stream. A DCR can continue accepting data while dashboards, alerts, or workbooks quietly stop matching the schema they were written for. Include representative records in deployment tests and verify that required security and operational fields survive the transformation unchanged.<\/p>\n DCRs are Azure resources with regional considerations. Some scenarios also involve Data Collection Endpoints for network access or collection architecture. Do not assume a DCR is purely logical and globally interchangeable.<\/p>\n Review where the rule is created, where the target workspace resides, and whether private connectivity or network restrictions require a DCE. Large enterprises should standardize these patterns so application teams do not invent different collection topologies for similar workloads.<\/p>\nDesign collection around questions you need to answer<\/h3>\n
Understand the DCR data flow before editing JSON<\/h3>\n
DCR associations determine which resources actually use the rule<\/h3>\n
Transformations are a cost and privacy control<\/h3>\n
Destination design should follow ownership and retention needs<\/h3>\n
Agent collection should be managed as infrastructure<\/h3>\n
Schema changes need explicit validation<\/h3>\n
Region and endpoint choices can affect architecture<\/h3>\n