The following CLI tools are required to run the commands on this page:
| Tool | Minimum version | Notes |
|---|---|---|
Latest | See the installation guide. Verify with | |
Azure CLI ( | 2.40 | Required for service principal and role assignment commands. Verify with |
Actions in this section must be performed by an Azure administrator with appropriate permissions.
Before running Azure CLI commands, ensure:
You have Azure CLI installed and authenticated (az login)
Your Azure account has one of the following:
Application Administrator role in Microsoft Entra ID
Cloud Application Administrator role in Microsoft Entra ID
microsoft.directory/servicePrincipals/create permission.
And one of the following:
Owner role at the target scope (subscription or management group)
User Access Administrator role at the target scope
A custom role with Microsoft.Authorization/roleAssignments/write permission
For Management Group monitoring scope, you need role assignment permissions at the management group level, not just individual subscriptions.
Decide which monitoring scope you'll use and gather the required IDs:
| Monitoring scope | Required information |
|---|---|
| Management Group ID (found in Azure portal under Management groups) |
| Subscription ID (found in Azure portal under Subscriptions) |
Dynatrace can poll Azure Monitor metrics only from subscriptions where the Microsoft.Insights resource provider is registered. Azure often registers it automatically—for example, when you create an alert rule or configure diagnostic settings—but not in every subscription. If it isn't registered, Dynatrace still discovers your topology but doesn't ingest metrics.
Check every subscription in your monitoring scope. For a Management Group scope, check every subscription beneath it. To register a resource provider, you need the Contributor or Owner role on the subscription. The Dynatrace service principal can't register it.
To check and register it in the Azure portal:
Microsoft.Insights. If the status is NotRegistered, select it and then select Register. If the status is Registering, wait until it shows Registered.To check it with Azure CLI:
az provider show --namespace Microsoft.Insights --subscription <SUBSCRIPTION_ID> --query registrationState --output tsv
If the output isn't Registered, run the following command. With --wait, the command returns once registration is complete.
az provider register --namespace Microsoft.Insights --subscription <SUBSCRIPTION_ID> --wait
For details, see Azure resource providers and types.
dtctl with your Dynatrace environment:Ensure your Dynatrace user has the correct permissions by completing the Create the Dynatrace IAM baseline steps.
dtctl auth login --context my-env --environment "https://<YOUR_ENVIRONMENT_ID>.apps.dynatrace.com"
Replace <YOUR_ENVIRONMENT_ID> with your Dynatrace environment ID (for example, abc12345).
Verify your configuration:
dtctl doctor
If this is the first time an Azure connection is created in this Dynatrace environment, install the Azure extension:
dtctl create extension --hub-extension com.dynatrace.extension.da-azure
A complete Azure monitoring setup requires two resources:
The shell commands on this page use \ for line continuation (bash/zsh). On Windows, replace \ with a backtick (`) in PowerShell, or ^ in command prompt.
The monitoring configuration requires an Azure connection to access your Azure environment. Dynatrace supports two authentication methods:
| Authentication method | Description | Notes |
|---|---|---|
Federated identity Recommended | Uses federated identity credentials. | More secure, passwordless authentication |
Uses a service principal with client secret. | Password-based authentication |
Federated identity credentials provide passwordless authentication and are more secure than client secrets.
This is the recommended approach for production environments.
Create the Azure connection in Dynatrace.
dtctl automatically generates and displays the exact issuer, subject, and audience values you will need in step 2.
dtctl create azure connection --name "<CONNECTION_NAME>" --type federatedIdentityCredential
Save the connection object ID from the command output. You'll need it when configuring the federated credential in Azure.
Configure the federated identity credential in Microsoft Entra ID using the values displayed in step 1.
Prepare for registering a new application in your Microsoft Entra ID tenant. For details, see How to register an app in Microsoft Entra ID
az ad sp create-for-rbac \--name "<CONNECTION_NAME>" \--create-password false \--query "{CLIENT_ID:appId, TENANT_ID:tenant}" \--output table
Replace the <CONNECTION_NAME> placeholder with a descriptive name for the connection (used in Dynatrace) and register a new application.
Prepare for creating a federated credential for the Microsoft Entra ID app using the issuer, subject, and audience displayed in step 1. Dynatrace uses this for OIDC token exchange. For details, see az ad app federated-credential.
az ad app federated-credential create \--id "<CLIENT_ID>" \--parameters '{"name": "<CONNECTION_NAME>-Federated-Credential", \"issuer": "https://token.dynatrace.com", \"subject": "dt:connection-id/<OBJECT_ID_FROM_STEP_1>", \"audiences": ["<DYNATRACE_ENVIRONMENT_ID>.apps.dynatrace.com/svc-id/com.dynatrace.da"]}'
Replace the following placeholders with your values and create a federated credential:
<CLIENT_ID>: Application (client) ID from the previous step<CONNECTION_NAME>: Descriptive name for the federated credential<OBJECT_ID_FROM_STEP_1>: The Azure connection ID (in objectId field) returned in step 1<DYNATRACE_ENVIRONMENT_ID>: Your Dynatrace environment ID (for example, abc12345)Get the object ID of the service principal.
az ad sp show --id "<CLIENT_ID>" --query "{OBJECT_ID:id}" --output table
Assign the Monitoring Reader Azure RBAC built-in role to the service principal at the appropriate monitoring scope.
For Management Group scope:
The --scope requires the management group resource ID, not its display name. To find it:
az account management-group list --query "[].{name:name, displayName:displayName}" --output table
Use the value in the Name column as <MANAGEMENT_GROUP_ID>.
az role assignment create \--assignee-object-id "<OBJECT_ID>" \--role "Monitoring Reader" \--scope "/providers/Microsoft.Management/managementGroups/<MANAGEMENT_GROUP_ID>" \--assignee-principal-type ServicePrincipal \--description "Dynatrace Monitoring"
For Subscription scope:
az role assignment create \--assignee-object-id "<OBJECT_ID>" \--role "Monitoring Reader" \--scope "/subscriptions/<SUBSCRIPTION_ID>" \--assignee-principal-type ServicePrincipal \--description "Dynatrace Monitoring"
Verify the role assignment was successful. You should see the Monitoring Reader role listed at your specified scope.
az role assignment list \--assignee-object-id "<OBJECT_ID>" \--output table
Update the connection with the tenant ID and application ID returned in step 2.
dtctl update azure connection --name "<CONNECTION_NAME>" --directoryId "<TENANT_ID>" --applicationId "<CLIENT_ID>"
Replace the following placeholders with your values:
<CONNECTION_NAME>: The connection name used in step 1<TENANT_ID>: Microsoft Entra ID tenant (directory) ID<CLIENT_ID>: Application (client) ID of the service principalIf the command returns an AADSTS70025 error, the federated credential is still propagating in Microsoft Entra ID. Wait a few seconds and retry.
For GitOps or infrastructure-as-code workflows, you can apply the same update using a YAML file instead of CLI flags. Populate the placeholders and run dtctl apply:
schemaId: builtin:hyperscaler-authentication.connections.azurescope: environmentobjectid: <CONNECTION_OBJECT_ID>value:name: "<CONNECTION_NAME>"type: federatedIdentityCredentialfederatedIdentityCredential:directoryId: "<TENANT_ID>"applicationId: "<CLIENT_ID>"consumers:- SVC:com.dynatrace.da
Replace the following placeholders with your values:
<CONNECTION_OBJECT_ID>: The connection object ID returned in step 1<CONNECTION_NAME>: The connection name used in step 1<TENANT_ID>: Microsoft Entra ID tenant (directory) ID<CLIENT_ID>: Application (client) ID of the service principaldtctl apply -f azure-connection-federated.yaml
After successful completion, proceed to Create a new Azure monitoring configuration using the CLI.
The monitoring configuration defines which Azure services to monitor, which regions to poll, and how to filter and enrich telemetry data.
Run the following command to get the active schema version of the Azure monitoring extension:
dtctl describe extension com.dynatrace.extension.da-azure
The output includes the active schema version:
...Active Version: 1.0.0...Available Versions:* 1.0.01.0.5
Use the Active Version value as <API_SCHEMA_VERSION> in the monitoring configuration YAML.
If you omit version from your YAML, dtctl apply automatically uses the latest available version and prints it to stderr. Run this command to see what version is used.
Create a monitoring configuration with defaults. By default, dtctl enables all *_essential feature sets and all Azure regions.
dtctl create azure monitoring --name "<CONFIGURATION_NAME>" --credentials "<CONNECTION_NAME>"
Replace the following placeholders with your values:
<CONFIGURATION_NAME>: Name of the monitoring configuration (letters, numbers, hyphens only; must start with a letter)<CONNECTION_NAME>: Name of the Azure connection created in the previous stepTo restrict the monitored regions or feature sets, use the optional flags:
| Flag | Description |
|---|---|
| Comma-separated Azure region names to monitor (for example, |
| Comma-separated feature set names to enable |
Run these commands to discover valid values for each flag:
dtctl get azure monitoring-locations # Lists all valid Azure region namesdtctl get azure monitoring-feature-sets # Lists all valid feature set names
To allow telemetry signals-in-context and inventory on all relevant regions, the topology service must poll for topology signals on all regions where any signal is ingested.
For more granular control—including subscription filtering, tag filtering, tag enrichment, and Dynatrace label mapping—create a YAML file and use dtctl apply.
The monitoring configuration supports additional filtering and enrichment options to customize what resources are monitored and how data is enriched in Dynatrace.
Control which Azure subscriptions to monitor using subscriptionfilteringmode and subscriptionFiltering.
Include mode: Monitor only specified subscriptions:
subscriptionfilteringmode: INCLUDEsubscriptionFiltering:- 00000000-0000-0000-0000-000000000001- 00000000-0000-0000-0000-000000000002
Exclude mode: Monitor all subscriptions except specified ones:
subscriptionfilteringmode: EXCLUDEsubscriptionFiltering:- 00000000-0000-0000-0000-000000000001
Filter which Azure resources to monitor based on their tags using tagfiltering.
Include mode: Monitor only resources with matching tags:
tagfiltering:- key: environmentvalue: productioncondition: INCLUDE- key: monitoringvalue: enabledcondition: INCLUDE
If you ingest Azure logs or events, also add the following entry to your include filters. For details, see Event Hubs requirements.
- key: managed-byvalue: dynatracecondition: INCLUDE
Exclude mode: Monitor all resources except those with matching tags:
tagfiltering:- key: monitoringvalue: disabledcondition: EXCLUDE
Azure tag-based filters instruct the Dynatrace poll services to include or exclude signals for ingest based on Azure tag key-value pairs.
If resources that don't match your filter are still monitored, see Troubleshooting.
Enrich Dynatrace signals with Azure resource tags by specifying tag keys in tagenrichment. The specified Azure tag keys are added as attributes to signals in Dynatrace.
tagenrichment:- environment- cost-center- application- team
Map Azure tags or literal values to Dynatrace labels using dtlabelsenrichment. This is particularly useful for cost allocation (dt.cost.costcenter, dt.cost.product) and security context (dt.security_context).
Using literal values
dtlabelsenrichment:dt.security_context:literal: productiontagkey: ""dt.cost.costcenter:literal: CC-12345tagkey: ""dt.cost.product:literal: MyProducttagkey: ""
Using Azure tags
dtlabelsenrichment:dt.security_context:literal: ""tagkey: environment # Azure tag key whose value is useddt.cost.costcenter:literal: ""tagkey: cost-centerdt.cost.product:literal: ""tagkey: product-name
When using tagkey, the value of the specified Azure tag is used as the label value in Dynatrace. Leave literal empty when using tagkey, and vice versa.
# objectid: <EXISTING_CONFIG_ID_IF_UPDATING>scope: integration-azurevalue:enabled: truedescription: <CONFIGURATION_NAME>azure:subscriptionfilteringmode: INCLUDEsubscriptionFiltering:- 00000000-0000-0000-0000-000000000001- 00000000-0000-0000-0000-000000000002credentials:- enabled: truedescription: <CONNECTION_NAME>connectionid: <AZURE_CONNECTION_OBJECT_ID>serviceprincipalid: <CLIENT_ID>type: FEDERATED # Use SECRET for clientSecret connectionslocationfiltering:- eastus- westeurope- northeurope# Run 'dtctl get azure monitoring-locations' for the complete listtagfiltering:- key: environmentvalue: productioncondition: INCLUDE- key: monitoringvalue: disabledcondition: EXCLUDEtagenrichment:- environment- cost-centerdtlabelsenrichment:dt.cost.costcenter:literal: ""tagkey: cost-centerdt.cost.product:literal: MyProducttagkey: ""dt.security_context:literal: ""tagkey: environmentfeaturesets:- microsoft_compute.virtualmachines_essential- microsoft_storage.storageaccounts_essential- microsoft_web.sites_functionapp_essential# Run 'dtctl get azure monitoring-feature-sets' for the complete list
dtctl apply -f azure-monitoring-config.yaml
If you encounter errors, validate that:
After successful completion, go to Settings > Cloud and virtualization > Azure. The newly created connection should be visible and in healthy state within a few minutes.
To inspect, update, or delete an existing connection or monitoring configuration, or to roll over the client secret of a service principal, see Manage your Azure connections via CLI.
Clouds. Azure resources with telemetry should start to appear shortly.For a full list of supported Azure services, including topology relationships and available metric collection sets, see Supported Azure services.
This error occurs when your Azure identity lacks permission to create applications in Microsoft Entra ID.
Solution: Ask your Azure administrator to grant you the Application Administrator role or create the service principal on your behalf.
This error occurs when your Azure identity lacks permission to assign roles at the specified scope.
Solution:
Owner or User Access Administrator role at the target subscription or management group.Management Group scope, verify you use the resource ID in --scope, not the display name. Run az account management-group list and use the Name column value. Display names differ from IDs and produce the same error.This error indicates that Microsoft Entra ID has not yet propagated the federated credential configured in step 2.
Solution: Wait a few seconds for propagation to complete, then retry the dtctl update azure connection command.
This error occurs when the Dynatrace platform token is invalid or lacks required permissions.
Solution:
dtctl config view to verify your environment URL and token reference are configured correctly.settings:schemas:read, settings:objects:read, settings:objects:write.An include filter can only match a resource that Azure reports the tag for. A resource remains monitored when:
Its Azure resource type doesn't support tags. Many types, especially child types, have no tags property. For example, Microsoft.DBforPostgreSQL/flexibleServers supports tags, but Microsoft.DBforPostgreSQL/flexibleServers/configurations doesn't. To check a type, see Tag support for Azure resources.
The tag is set on the resource group or the parent resource, not on the resource. Azure resources don't inherit tags from a resource group or subscription, and Dynatrace doesn't propagate tags from a parent resource to its children. The same applies to resources in Azure-managed resource groups, such as the MC_<cluster-name>_<region> group that Azure Kubernetes Service creates. Dynatrace collects these resources together with their parent, but Azure doesn't inherit the parent's tags to them. Configure tag inheritance in Azure instead. For details, see Configure tag inheritance in Azure.
Solution: To find the resources your include filter can't match, run the query in Verify which entities your tag filter matches.
This issue occurs when resources from a subscription appear in
Clouds but have no metrics, while metrics arrive for other subscriptions on the same connection. The connection reports as healthy, and Dynatrace might log DATA_ACQUISITION_EVENT warnings that report the identity isn't authorized to query metric data.
Two causes produce this symptom:
Monitoring Reader role at subscription scope or higher. Dynatrace polls metrics with the Azure Monitor metrics:getBatch API, which is a subscription-level API. The request fails unless the service principal has Monitoring Reader on the subscription itself, either assigned directly or inherited from a management group. A role assigned only on resource groups or individual resources isn't enough, even if it covers every resource in the subscription. For details, see 401 authorization errors.Microsoft.Insights resource provider isn't registered in the affected subscription. Azure Monitor doesn't return metrics for a subscription without it, even when the service principal has the Monitoring Reader role. For details, see 403 authorization failures.Solution:
Verify that the service principal has the Monitoring Reader role at subscription scope or higher:
az role assignment list --assignee <CLIENT_ID> --subscription <SUBSCRIPTION_ID> --include-inherited --query "[?roleDefinitionName=='Monitoring Reader'].scope" --output tsv
If the output is empty, assign the role at subscription or management group scope. For details, see Assign Azure roles using Azure CLI.
Check and register Microsoft.Insights in the affected subscription.
Wait for the next polling cycles. The metric poller runs every five minutes.
To find the warning events for your connection, run this query. Replace <CONFIGURATION_ID> with the Monitoring Configuration ID shown on the Overview tab of your connection. For details, see Connection properties.
fetch dt.system.events| filter event.kind == "DATA_ACQUISITION_EVENT"| filter da.clouds.configurationId == "<CONFIGURATION_ID>"| sort timestamp desc