Data collection rules in Azure Monitor
Data Collection Rules (DCRs) define the data collection process in Azure Monitor. DCRs specify what data should be collected, how to transform that data, and where to send that data. Some DCRs will be created and managed by Azure Monitor to collect a specific set of data to enable insights and visualizations. You may also create your own DCRs to define the set of data required for other scenarios.
View data collection rules
To view your data collection rules in the Azure portal, select Data Collection Rules from the Monitor menu.
While this view shows all data collection rules in the specified subscriptions, clicking the Create button will create a data collection for Azure Monitor agent. Similarly, this page will only allow you to modify data collection rules for the Azure Monitor agent. See Creating a data collection rule below for guidance on creating and updating data collection rules for other workflows.
Create a data collection rule
The following resources describe different scenarios for creating data collection rules. In some cases, the data collection rule may be created for you, while in others you may need to create and edit it yourself.
|Azure Monitor agent||Configure data collection for the Azure Monitor agent||Use the Azure portal to create a data collection rule that specifies events and performance counters to collect from a machine with the Azure Monitor agent and then apply that rule to one or more virtual machines. The Azure Monitor agent will be installed on any machines that don't currently have it.|
|Use Azure Policy to install Azure Monitor agent and associate with DCR||Use Azure Policy to install the Azure Monitor agent and associate one or more data collection rules with any virtual machines or virtual machine scale sets as they're created in your subscription.|
|Custom logs||Configure custom logs using the Azure portal
Configure custom logs using Resource Manager templates and REST API
|Send custom data using a REST API. The API call connects to a DCE and specifies a DCR to use. The DCR specifies the target table and potentially includes a transformation that filters and modifies the data before it's stored in a Log Analytics workspace.|
|Workspace transformation||Configure ingestion-time transformations using the Azure portal
Configure ingestion-time transformations using Resource Manager templates and REST API
|Create a transformation for any supported table in a Log Analytics workspace. The transformation is defined in a DCR that's then associated with the workspace and applied to any data sent to that table from a legacy workload that doesn't use a DCR.|
Work with data collection rules
See the following resources for working with data collection rules outside of the Azure portal.
|API||Directly edit the data collection rule in any JSON editor and then install using the REST API.|
|CLI||Create DCR and associations with Azure CLI.|
|PowerShell||Work with DCR and associations with the following Azure PowerShell cmdlets.
Structure of a data collection rule
Data collection rules are formatted in JSON. While you may not need to interact with them directly, there are scenarios where you may need to directly edit a data collection rule. See Data collection rule structure for a description of this structure and the different elements used for different workflows.
When using programmatic methods to create data collection rules and associations, you require the following permissions:
||Create or edit data collection rules|
|Virtual Machine Contributor
Azure Connected Machine Resource Administrator
||Deploy associations (i.e. to assign rules to the machine)|
|Any role that includes the action Microsoft.Resources/deployments/*||
||Deploy ARM templates|
For limits that apply to each data collection rule, see Azure Monitor service limits.
Data collection rules are available in all public regions where Log Analytics workspace are supported, as well as the Azure Government and China clouds. Air-gapped clouds are not yet supported.
Single region data residency is a preview feature to enable storing customer data in a single region and is currently only available in the Southeast Asia Region (Singapore) of the Asia Pacific Geo and Brazil South (Sao Paulo State) Region of Brazil Geo. Single region residency is enabled by default in these regions.
Data resiliency and high availability
A rule gets created and stored in a particular region and is backed up to the paired-region within the same geography. The service is deployed to all three availability zones within the region, making it a zone-redundant service which further increases availability.
Submit and view feedback for