az monitor metrics list-definitions --resource <resource-id>
Monitoring and Observability
Azure Monitor Metrics
Metric dimension
Metric dimension is a property attached to metric data that lets Azure Monitor split, filter, or group the same metric by useful values. Teams should manage it with clear ownership, monitoring, rollback evidence, and production change discipline.
Source: Microsoft Learn - Azure Monitor Metrics overview Reviewed 2026-05-16T05:38:39Z
- Exam trap
- Changing Metric dimension without checking dependent resources, owner approval, monitoring signals, and rollback steps first.
- Production check
- Confirm the resource name, subscription, region, scope, owner tag, and production environment before making any change.
Article details and learning context
- Aliases
- metric split, metric label, dimension value
- Difficulty
- fundamentals
- CLI mappings
- 4
- Last verified
- 2026-05-16T05:38:39Z
Related context
No curated learning path mapped yet; use the category trail.
Understand the concept
In plain English
Metric dimension is a property attached to metric data that lets Azure Monitor split, filter, or group the same metric by useful values. In everyday Azure work, it appears when operators need to see which instance, status code, queue, region, operation, or dependency is driving a metric trend. The useful mental model is a label on a metric series that turns one chart into many explainable slices. Treat it as an operating decision, not a loose label: identify the owner, scope, dependent workload, monitoring signal, and rollback path before changing it in production.
Why it matters
Metric dimension matters because it helps teams find the specific source of a problem instead of reacting to an average across many hidden contributors. A weak definition causes teams to change the wrong setting, misread symptoms, or accept defaults that do not fit the workload. The value is not just the feature itself; it is the evidence around it. A strong page explains who owns it, which resource or workflow depends on it, how operators verify health, and what must happen before a production change. That shared understanding makes audits, migrations, scale events, and incidents less chaotic. This keeps owners, operators, and reviewers aligned on the same production evidence.
Official wording and source
Microsoft Learn describes Metric dimension as a name-value pair that splits Azure Monitor metric data by a property such as resource, instance, status, or operation. Teams use it to analyze metric behavior by meaningful slices. Operators should verify scope, permissions, monitoring, and rollback evidence.
Technical context
Technically, Metric dimension sits in the Azure Monitor metrics layer across time-series data, metric definitions, charts, alert conditions, and dimensional filtering. Azure represents it through dimension names, dimension values, filter clauses, split-by settings, chart legends, and alert criteria. It usually depends on the monitored resource provider, metric definition, data collection behavior, cardinality limits, and alert rule design. The important boundary is that dimensions are metric labels; they are not tags, log fields, or free-form metadata on the resource itself.
Exam context
Compare with
Where it is used
Where you see it
- In the Azure portal, Metric dimension appears on metrics explorer dimension filters, split-by controls, alert condition builders, chart legends, and workbook visualizations, where operators confirm state, ownership, and release evidence.
- In CLI, SDK, REST, or diagnostic output, Metric dimension appears as metric definition output, metric list filters, dimension names, dimension values, and alert rule criteria, helping teams compare live state with design.
- In architecture, audit, or incident reviews, Metric dimension appears when teams discuss root-cause analysis, noisy alert splits, per-instance health, capacity planning, and operational dashboard design, then decide which evidence proves health.
Common situations
- Split a metric by instance, operation, status, or region.
- Build more precise metric alerts with dimension filters.
- Find the failing slice hidden inside an average.
- Avoid high-cardinality dashboards that slow review.
Illustrative Azure scenarios
These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.
Scenario 01 API endpoint isolation. Scenario, objectives, solution, measured impact, and takeaway.
Scenario
PulseBridge Software monitored average request duration, but one broad metric hid which API endpoint slowed during clinic registration peaks.
Goals
- Identify the slow endpoint within five minutes.
- Avoid paging every application team.
- Reduce mean time to isolate by 50%.
- Keep dashboard filters reusable.
Approach using Metric dimension
The observability team used Metric dimension values for operation name and cloud role instance in Application Insights metrics. They updated dashboards to split request duration by endpoint and configured alert rules to include the most important dimension filters. CLI output listed metric definitions and confirmed the alert rule conditions. Runbooks explained which dimension to check first during incidents. The team documented the owner, rollback signal, monitoring evidence, and support handoff so reviewers could verify the change during normal release governance. They also added a runbook note that explained the expected healthy signal, the first diagnostic command, and the escalation path for production incidents. Change evidence was captured in JSON output and attached to the release ticket for audit review, incident learning, and future tuning decisions.
Potential outcomes
- Mean time to isolate dropped from 24 minutes to 7 minutes.
- Only the registration API team was paged for the pilot incident.
- Dashboard reuse improved across four application squads.
- Incident notes included exact endpoint and instance evidence.
What to learn
Metric dimensions help teams move from vague resource health to the exact workload slice causing pain.
Scenario 02 Disk pressure by drive. Scenario, objectives, solution, measured impact, and takeaway.
Scenario
ForgeLine Manufacturing monitored VM disk space, but aggregate charts missed that one data drive filled while the operating system drive looked healthy.
Goals
- Show disk pressure per drive.
- Trigger alerts only for affected drives.
- Reduce unnecessary VM restarts.
- Improve root-cause notes for support.
Approach using Metric dimension
Operators used Metric dimension filters on the disk-space metric to split values by drive. They updated the alert condition to evaluate only the data drives that mattered for the production application and added the split view to the workbook. CLI commands listed metric definitions and exported the alert rule for change control. The team documented the owner, rollback signal, monitoring evidence, and support handoff so reviewers could verify the change during normal release governance. They also added a runbook note that explained the expected healthy signal, the first diagnostic command, and the escalation path for production incidents. Change evidence was captured in JSON output and attached to the release ticket for audit review, incident learning, and future tuning decisions. The implementation notes included sample alerts, expected owner actions, and rollback criteria so production teams could operate the feature confidently after handoff.
Potential outcomes
- Disk-pressure incidents were isolated in under six minutes.
- Unnecessary VM restarts dropped 63%.
- Alert noise from unaffected drives was removed.
- Support notes now named the exact drive and VM instance.
What to learn
A dimension can turn a noisy aggregate metric into an actionable troubleshooting signal.
Scenario 03 Model traffic split. Scenario, objectives, solution, measured impact, and takeaway.
Scenario
VisionHarbor AI hosted multiple document models behind one service, and total request metrics did not show which model consumed capacity.
Goals
- Split model requests by model name.
- Identify expensive model traffic patterns.
- Create targeted alerts for the highest-risk model.
- Support cost review with metric evidence.
Approach using Metric dimension
The team reviewed supported metric dimensions for the AI resource and used the model dimension in Metrics Explorer. Dashboards split request count, latency, and errors by model. A metric alert watched the high-volume model separately from lower-risk deployments. CLI output captured metric definitions and alert configuration for FinOps and operations review. The team documented the owner, rollback signal, monitoring evidence, and support handoff so reviewers could verify the change during normal release governance. They also added a runbook note that explained the expected healthy signal, the first diagnostic command, and the escalation path for production incidents. Change evidence was captured in JSON output and attached to the release ticket for audit review, incident learning, and future tuning decisions.
Potential outcomes
- The highest-cost model was identified within one day.
- Targeted alerting reduced false pages by 45%.
- FinOps received model-level usage evidence.
- Capacity tuning focused on the two models driving most traffic.
What to learn
Metric dimensions make shared services easier to operate because each workload slice can be measured separately.
Azure CLI
Azure CLI is useful for Metric dimension because it turns portal state into repeatable evidence. Operators can inspect scope, identity, configuration, metrics, dependencies, and related resources before approving a change. CLI output also supports automation, audit packages, rollback reviews, and incident handoffs.
Useful for
- Inventory Metric dimension across the relevant resource, workspace, account, group, endpoint, or scope before a production review.
- Inspect live Metric dimension state during troubleshooting, migration planning, access review, release validation, or rollback confirmation.
- Export JSON output so reviewers can compare actual configuration with architecture diagrams, source-controlled definitions, and approved runbooks.
- Run read-only commands first; use create, update, or delete commands only through an approved change path.
Before you run a command
- Confirm tenant, subscription, resource group, workspace, account, namespace, server, endpoint, or policy scope before running commands.
- Verify your role assignment allows the read, write, monitoring, data, or governance action you plan to perform.
- Choose JSON, table, or TSV output intentionally so the result can be reviewed, scripted, or attached as evidence.
- For production changes, confirm owner approval, maintenance window, rollback path, cost impact, and dependent workloads first.
What the output tells you
- Names, IDs, scopes, and regions confirm whether you are looking at the intended Metric dimension boundary, not a similarly named test asset.
- State, SKU, version, identity, network, metric, and configuration fields show whether live behavior matches the approved design.
- Errors, timestamps, and provisioning states help separate service configuration issues from application, data, identity, or caller problems.
- Saved output gives release, audit, and incident teams a shared record for comparison after the next change.
Mapped commands
Command group
az monitor metrics list --resource <resource-id> --metric <metric-name> --dimension <dimension-name>az monitor metrics alert show --resource-group <group> --name <alert>az monitor metrics list-namespaces --resource <resource-id>Architecture context
Architecturally, Metric dimension belongs to the Azure Monitor metrics layer across time-series data, metric definitions, charts, alert conditions, and dimensional filtering. It connects to the monitored resource provider, metric definition, data collection behavior, cardinality limits, and alert rule design. Treat it as a production boundary with explicit ownership, dependencies, monitoring, and rollback evidence. A diagram or runbook should show who can change it, what resources rely on it, and which outputs prove the intended configuration.
- Security
- Security for Metric dimension focuses on dimension values that expose sensitive names, broad monitoring-reader access, and alert routing that reveals operational details to the wrong audience. The main risk is treating it as harmless configuration while it may affect access, exposure, data handling, or automated response. Review who can read, create, update, delete, invoke, or bypass the related resource, and whether that permission is direct, inherited, or granted through a deployment pipeline. Prefer managed identity, least privilege, private access, encryption, monitored changes, and clear exception ownership wherever the Azure service supports those controls. Keep evidence in the change record. This keeps owners, operators, and reviewers aligned on the same production evidence.
- Cost
- Cost for Metric dimension is driven by high-cardinality alert rules, noisy notifications, support time, and duplicated dashboards when dimensions are chosen poorly. Some costs are direct, such as compute, storage, ingestion, action execution, capacity, or retained data. Other costs are indirect: failed retries, duplicated work, noisy alerts, unused resources, delayed migrations, or engineering time spent troubleshooting unclear ownership. FinOps reviews should identify who pays, which metric or SKU drives the bill, and whether a cheaper setting still meets security, reliability, compliance, and performance requirements. Do not cut cost by removing evidence or weakening controls silently. This keeps owners, operators, and reviewers aligned on the same production evidence.
- Reliability
- Reliability for Metric dimension depends on whether alerts and dashboards split signals accurately enough to isolate failing instances, operations, or regions during incidents. The concern is not only that the setting exists; it is whether the workload behaves predictably during deployment, scale, maintenance, dependency loss, retry, recovery, and operator error. Production teams should know which metric, log, activity record, or CLI output proves healthy behavior. They should also document what failure looks like, how to roll back, and which dependent services must be checked before the incident is closed. Good reliability practice makes the term operational, not decorative. This keeps owners, operators, and reviewers aligned on the same production evidence.
- Performance
- Performance for Metric dimension depends on query and chart responsiveness, alert evaluation complexity, cardinality, aggregation accuracy, and the speed of identifying the failing slice. The right signal may be request latency, queue depth, startup time, query duration, chart responsiveness, job runtime, throughput, alert delay, or operator time to isolate a bottleneck. Measure before and after important changes rather than assuming the setting improves speed. Keep enough metrics, logs, and command output to explain whether Azure configuration helped the workload, hid the problem, or simply moved the bottleneck to another component. This keeps owners, operators, and reviewers aligned on the same production evidence.
- Operations
- Operationally, Metric dimension requires choosing useful split-by values, avoiding excessive cardinality, validating dimension availability, and documenting alert filters. Operators should know which portal blade, CLI command, SDK property, metric, activity log, deployment output, or runbook step shows the live state. Avoid undocumented portal-only edits in production. Use scripts, tags, source-controlled definitions, diagnostics, and change records so support staff can compare actual configuration with the approved design during releases, audits, and incidents. After any change, capture evidence, confirm dependent workloads still behave correctly, and record the owner responsible for follow-up. This keeps owners, operators, and reviewers aligned on the same production evidence.
Common mistakes
- Changing Metric dimension without checking dependent resources, owner approval, monitoring signals, and rollback steps first.
- Assuming a portal label tells the whole story instead of validating live state through CLI, logs, diagnostics, or activity history.
- Granting broad permissions for convenience when a narrower role, managed identity, group assignment, or read-only path would work.
- Optimizing cost or speed while ignoring security, reliability, data exposure, recovery behavior, or user-facing impact.
Copied command