Azure metrics

Latest Dynatrace
Explanation

Azure Cloud Platform Monitoring ingests any Azure Monitor native platform metric from any Azure service that sends metrics to Azure Monitor.

The metric ingest strategy lets you quickly onboard with recommended services and metrics. You can also customize using advanced settings during or after onboarding.

Dynatrace uses the Azure Monitor APIs to poll metrics. The service principal associated with your Azure connection must have the Monitoring Reader role assigned at minimum subscription scope.

Metric ingest methods

The Dynatrace Azure Cloud Platform Monitoring was designed to support the following Azure Monitor metrics ingest method:

Poll-based: The Dynatrace SaaS metric poller calls the Azure Monitor getBatch and ListMetricDefinitions APIs to validate, poll, and persist metrics.

The metric poller is scheduled every 5 minutes, evaluating a 5-minute window with a 5-minute delay. A metric poller job which started at 9:00 AM therefore evaluates the data points for 8:50 AM-8:55 AM (a 5-minute delay plus a 5-minute window). The evaluation delay is necessary because Azure Monitor is an eventually consistent metrics API. Azure Monitor takes a few minutes (late aggregations) to make the latest data points available.

Metrics observability options

The metric observability options consist of the following key elements.

Recommended Azure services

Recommended services represent a logical group of Dynatrace opinionated native Azure Services, and their corresponding recommended metrics.

When onboarding an Azure subscription following the Recommend path, the recommended services are enabled by default.

The recommended services list is constantly evaluated based on customer feedback and Azure innovation; Dynatrace may change the list to reflect user feedback and/or to keep up with the Azure innovation. Any changes are designed not to introduce breaking changes for existing Azure connections.

Metric collection sets

A metric collection set is a group of metrics assigned to a supported Azure service. Once assigned, all metrics in this collection set are scheduled for polling.

Only a single metric collection set can be assigned to a service at any given time (1:1).

Metric collection set types

Recommended: A customer-immutable list of opinionated Dynatrace recommended metrics (per cloud service). An optimal starting point.
Recommended+Custom: Always includes all metrics from the Recommended set. In addition, you can cherry-pick individual metrics from a larger Dynatrace curated list.
Auto-discovery: All metrics for a specific Azure service are auto-discovered and marked for polling. This option has the potential to generate elevated Azure Monitor and Dynatrace costs.

To view the most updated list of metrics that the Recommended metric collection set ingests (per Azure service):

Go to Hub.
In search, enter preview, then select the Azure Cloud Monitoring tile.
Scroll down, and in the Feature Sets section, search metrics using this pattern: [Azure Resource Type]_essential, for example microsoft_apimanagement.service_essential.

For an overview of supported Azure services and available metrics, see Supported Azure services.

All metrics across each metric collection set are designed to support the signals-in-context principle, where they are linked to their respective Dynatrace entity. This enables the following use cases:

Clouds metrics in-context view (view the metrics related to the Azure resource).
Enrichment of those metrics with cloud extended metadata as attributes (azure.subscription.id, azure.region, azure.tag, azure.tag.[TagKeyName]:value), allowing advanced filtering use cases.

Advanced metrics ingest use cases

Ingest any Azure Monitor metrics

In addition to the predefined metric collection sets, you can configure Dynatrace to collect any Azure Monitor native platform metric. This enables monitoring of:

Metrics not included in the standard collection sets
Metrics from Azure services not yet fully supported by Dynatrace

To use this feature, you must provide precise details about the Azure resource type and metric definition. Incorrect values result in failed metric collection.

When configuring a custom metric, you specify the following:

Field	Required	Description
Type	Yes	The Azure resource type (for example, `Microsoft.Compute/virtualMachines`). This must match the resource provider namespace and type exactly as defined in Azure.
Kinds	No	Comma-separated list of resource kinds to filter (for example, `Standard,Premium`). Leave empty to include all kinds.
SKU name	No	Filter by specific SKU name if the resource type supports SKUs.
Suffix	No	Resource type suffix for specialized resource variants.
Name	Yes	The metric name as defined in Azure Monitor (for example, `Percentage CPU`). Must match the exact metric name from Azure Monitor.
Dimensions	No	Comma-separated list of dimensions to include in metric collection. Use dimensions to split metrics by specific attributes.
Time grain	Yes	The aggregation interval for the metric (for example, `PT1M` for 1 minute, `PT5M` for 5 minutes).
Statistics	Yes	The aggregation type to apply (for example, `Average`, `Sum`, `Minimum`, `Maximum`, `Count`).

To find the correct metric names, resource types, and available dimensions, refer to the Azure Resource Graph and the Azure Monitor supported metrics documentation.

Supported Azure services

For a full list of supported Azure services, including topology relationships and available metric collection sets, see Supported Azure services.

Metric keys and dimensions

Every metric ingested by this integration uses the same key shape and always carries dt.da.source == "azure-metric-poller", so you can filter to this integration's data regardless of what else runs on the same tenant.

Metric key format

Metric keys follow the pattern cloud.azure.<namespace>.<MetricName>:

<namespace> is the ARM resource type in lowercase, with the provider prefix collapsed (for example, Microsoft.Cache/redis becomes microsoft_cache.redis).
<MetricName> is the metric name exactly as Azure Monitor defines it, including its casing (for example, ConnectedClients, not connectedclients).

For example, the "Connected clients" metric for Azure Cache for Redis has the key cloud.azure.microsoft_cache.redis.ConnectedClients.

Query metrics with DQL

Use timeseries with the metric key, scoped with dt.da.source to be explicit about the source:

timeseries avg(cloud.azure.microsoft_cache.redis.ConnectedClients), filter: dt.da.source == "azure-metric-poller"

You can also browse available keys directly:

metrics
| filter startsWith(metric.key, "cloud.azure")
| filter dt.da.source == "azure-metric-poller"
| fields metric.key, azure.subscription
| dedup metric.key

Dimensions are lowercase

The Azure metric poller lowercases every dimension name before it reaches Grail. The dimension names documented on Supported Azure services, such as ShardId or ApiName, are the names Azure Monitor uses, not the attribute keys you query in Grail. Use the lowercase form (shardid, apiname) in DQL.

Dynatrace will update metric metadata in the UI to use the lowercase form consistently. Until that rollout completes, you may still see a PascalCase dimension name displayed alongside lowercase data.

Avoid key collisions with classic Azure monitoring

If classic Azure monitoring is also enabled for the same Azure resources—typically only while migrating—a small number of metrics have a key identical to their classic cloud-service equivalent except for the ext: prefix that classic uses. For example, classic's ext:cloud.azure.microsoft_cache.redis.connectedclients against this integration's cloud.azure.microsoft_cache.redis.connectedclients. You can confuse the two in the metric picker, which shows the same display name for both, or when you write a key by hand.

Filtering on dt.da.source == "azure-metric-poller", as in Query metrics with DQL, always isolates this integration's data, so it's the reliable way to pick the right one when a key looks ambiguous.

Existing dashboards and alerts built on classic keys keep working when you enable this integration, because they reference the classic key, which this integration doesn't write to. The risk is only when you build something new and pick the wrong entry.

Running classic Azure monitoring and this integration against the same Azure resources isn't recommended outside of a migration window, as you pay to poll and ingest the same data twice. Once you've validated data from this integration, turn off classic monitoring for those resources.

Dynatrace plans to add a (Classic) suffix to classic metrics' display names, so that, for example, Response status becomes Response status (Classic). Until that ships, use the metric key and dimension casing to tell them apart.

To plan a move from classic Azure monitoring to this integration, see Upgrade from classic to new cloud connections, which includes per-resource Azure metric and entity mapping tables. For the Grail metric-key renaming that classic built-in metrics went through, see Built-in metrics on Grail.

Limitations

Azure Monitor Metric Streaming is not currently planned.
Telemetry signals enrichment with metadata such as Azure tags is only possible for signals which were successfully linked to an entity (Azure Resource).
The maximum number of user provided Azure tags for enrichment is 20.
The maximum number of tag-based filtering is up to 5 for include and 5 for exclude.