az monitor metrics list-namespaces --resource <resource-id>
Monitoring and Observability
Azure Monitor Metrics
Metric namespace
Metric namespace is a category container that groups related Azure Monitor metrics for a resource type or service. Teams should manage it with clear ownership, monitoring, rollback evidence, and production change discipline.
Source: Microsoft Learn - Azure Monitor metrics explorer with PromQL Reviewed 2026-05-16T05:38:39Z
- Exam trap
- Changing Metric namespace 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
- metrics namespace, metric category, Azure Monitor metric namespace
- Difficulty
- fundamentals
- CLI mappings
- 4
- Last verified
- 2026-05-16T05:38:39Z
Learning paths
Learn
Observability and Incident Response
Metric namespace
Related context
Learning path: Observability and Incident Response
Understand the concept
In plain English
Metric namespace is a category container that groups related Azure Monitor metrics for a resource type or service. In everyday Azure work, it appears when operators browse available metrics for storage, compute, databases, applications, networking, or custom telemetry and need the correct metric family. The useful mental model is the folder that helps you find the right metric names for a resource. 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 namespace matters because it prevents teams from choosing the wrong signal or missing a better metric that already exists for the resource. 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 namespace as a grouping that organizes Azure Monitor metrics for a resource provider or service area. Teams use it to find the right metric family for a resource. Operators should verify scope, permissions, monitoring, and rollback evidence.
Technical context
Technically, Metric namespace sits in the Azure Monitor metrics catalog across resource providers, metric definitions, alert rules, dashboards, and workbooks. Azure represents it through namespace names, metric definitions, resource type associations, dimensions, units, aggregations, and supported time grains. It usually depends on resource provider metric support, diagnostic configuration, custom metric publishing, region availability, and monitoring permissions. The important boundary is that a namespace groups metric definitions; it is not a Log Analytics workspace, table, or resource group.
Exam context
Compare with
Where it is used
Where you see it
- In the Azure portal, Metric namespace appears on Metrics Explorer namespace dropdowns, alert condition builders, workbook data sources, and resource monitoring pages, where operators confirm state, ownership, and release evidence.
- In CLI, SDK, REST, or diagnostic output, Metric namespace appears as metric namespace lists, metric definition output, alert criteria, and resource provider metric metadata, helping teams compare live state with design.
- In architecture, audit, or incident reviews, Metric namespace appears when teams discuss monitoring design, dashboard consistency, metric selection, custom telemetry decisions, and alert rule evidence, then decide which evidence proves health.
Common situations
- Find metrics available for a specific Azure resource type.
- Choose the correct namespace before building an alert.
- Document which metric family supports a runbook.
- Avoid confusing platform metrics with log tables.
Illustrative Azure scenarios
These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.
Scenario 01 Correct signal discovery. Scenario, objectives, solution, measured impact, and takeaway.
Scenario
ClearDesk SaaS built dashboards for customer API latency, but engineers kept mixing platform metrics with application metrics and misreading trends.
Goals
- Standardize metric selection for API dashboards.
- Reduce wrong-chart incidents by 60%.
- Document metric namespaces for support.
- Improve alert authoring accuracy.
Approach using Metric namespace
The observability lead documented the Metric namespace choices for each application resource. Metrics Explorer dashboards used the correct namespace before selecting request duration, failure count, and dependency metrics. CLI list-namespaces and list-definitions commands were added to the support runbook so operators could verify namespace and metric names before changing alerts. 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
- Wrong-chart incidents dropped 71%.
- Alert authoring rework fell by 38%.
- Support runbooks listed approved namespaces for each resource type.
- Engineers resolved metric-selection questions without escalation.
What to learn
Metric namespace gives operators a reliable starting point for finding the right metric signal.
Scenario 02 Storage monitoring cleanup. Scenario, objectives, solution, measured impact, and takeaway.
Scenario
LakeHouse Direct monitored several storage accounts, but dashboard authors selected inconsistent metric namespaces and produced conflicting capacity charts.
Goals
- Use consistent metric namespaces across storage dashboards.
- Remove duplicate or misleading charts.
- Improve monthly capacity review accuracy.
- Create repeatable CLI checks for analysts.
Approach using Metric namespace
The team inventoried Metric namespace values for each storage account and documented which namespaces belonged in operational dashboards. They rebuilt charts around approved metric definitions and retired charts using the wrong namespace. Analysts used CLI commands to list namespaces and metric definitions before adding new visuals. Change notes tied each dashboard panel to an owner and metric source. 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
- Duplicate storage charts were reduced by 52%.
- Capacity review corrections dropped by 47%.
- New dashboard requests included namespace evidence.
- Analysts could validate metric families without portal-only screenshots.
What to learn
Choosing the right namespace prevents monitoring work from becoming a pile of similar-looking but inconsistent charts.
Scenario 03 Managed metrics migration. Scenario, objectives, solution, measured impact, and takeaway.
Scenario
BeaconOps Platform moved Prometheus metrics into Azure Monitor workspaces, and teams needed a clear way to choose standard versus Prometheus-backed metric sources.
Goals
- Separate resource metrics from workspace metrics.
- Reduce migration confusion for application teams.
- Keep alert rules tied to approved metric sources.
- Document the new discovery workflow.
Approach using Metric namespace
Architects explained Metric namespace as the first selection step in Metrics Explorer and API queries. They published a migration runbook showing how to list namespaces, select the workspace scope, choose the correct namespace, and verify metric definitions before creating alerts. CLI checks and dashboard examples were included for each migrated service. 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
- Migration support tickets fell 49%.
- Alert-rule rework dropped by 35%.
- Application teams adopted the namespace checklist for new metrics.
- Platform owners gained consistent evidence for migrated dashboards.
What to learn
Metric namespaces help teams navigate expanding metric sources without guessing which signal family they are using.
Azure CLI
Azure CLI is useful for Metric namespace 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 namespace across the relevant resource, workspace, account, group, endpoint, or scope before a production review.
- Inspect live Metric namespace 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 namespace 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-definitions --resource <resource-id> --namespace <metric-namespace>az monitor metrics list --resource <resource-id> --metric <metric-name> --namespace <metric-namespace>az monitor metrics alert show --resource-group <group> --name <alert>Architecture context
Architecturally, Metric namespace belongs to the Azure Monitor metrics catalog across resource providers, metric definitions, alert rules, dashboards, and workbooks. It connects to resource provider metric support, diagnostic configuration, custom metric publishing, region availability, and monitoring permissions. 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 namespace focuses on monitoring permissions, custom metric names, dashboard exposure, and alert configuration that may reveal sensitive workload structure. 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 namespace is driven by misconfigured alerts, duplicated metric exploration, custom metric ingestion, and support time spent chasing unavailable signals. 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 namespace depends on whether dashboards and alerts use supported metrics that continue to report during incidents, scale events, and provider changes. 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 namespace depends on metric discovery speed, chart query behavior, alert evaluation, and how quickly operators can select the right telemetry source. 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 namespace requires listing namespaces, confirming metric availability, mapping alerts to resource types, and documenting which signals support each runbook. 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 namespace 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