Azure Monitor brings together platform metrics, logs, traces, alerts, workbooks, and application telemetry.
Metrics provide efficient numeric time series, Log Analytics stores queryable records, and Application Insights follows application requests, dependencies, exceptions, and traces.
A useful monitoring design starts with user-visible health and service objectives, then links those outcomes to resource saturation, dependencies, deployments, and configuration changes.
Use diagnostic settings to route supported resource logs and metrics to suitable destinations. Configure agents or data collection rules when guest operating-system telemetry is required.
Kusto Query Language filters, joins, summarizes, and charts records in Log Analytics. Correlation IDs and distributed tracing connect a front-end request to dependencies and background processing.
Metric, log-search, activity-log, and service-health alerts serve different purposes. Each alert should identify impact, owner, notification route, and response.
Workspace ingestion, retention, high-cardinality telemetry, and duplicate collection can become significant costs. Review tables, sampling, daily caps, archive needs, and query usage.
Azure Monitor receives platform metrics, resource logs, Activity Log records, application telemetry, guest data, Prometheus metrics, and other sources through different collection paths. Metrics enter a time-series store optimized for fast aggregation and alerting; logs enter Log Analytics workspaces for Kusto Query Language analysis. Do not assume enabling one automatically captures the other.
Start from a critical user flow and define availability, latency, correctness, throughput, and freshness indicators. Then map resource and dependency signals that explain those outcomes. Platform CPU or request count is supporting evidence, not a substitute for measuring whether users completed the operation successfully.
Record subscription, resource ID, Region, application, environment, release, and correlation context consistently. Use resource-centric and workspace-centric views deliberately. A central workspace improves cross-resource investigation but also creates access, retention, residency, ingestion, and query-cost decisions.
Resource diagnostic settings route supported log categories and metrics to destinations such as Log Analytics, Storage, Event Hubs, or partners. Category support differs by resource provider and can evolve. Select categories from audit and operational needs, verify delivery, and deploy settings through Policy or infrastructure code where broad consistency is required.
Data collection rules define selected collection, transformation, and destinations for agents and modern telemetry paths. Scope them carefully so one rule does not duplicate or drop data unexpectedly. Track which resource association owns each stream and test a known record after every change.
The Activity Log records control-plane events at subscription scope and needs export for longer or centralized retention. Data-plane access needs service-specific logs. Store immutable or long-retention evidence outside the same administrator boundary when the threat model requires it, and protect workspace query access because logs can contain sensitive business context.
Application Insights provides application performance monitoring over requests, dependencies, exceptions, traces, availability tests, and application metrics. Instrument with the supported Azure Monitor OpenTelemetry distribution or current SDK path for the application stack, and preserve W3C trace context across HTTP, queues, and background processing.
Sampling controls volume and cost but changes analysis. Keep head or tail strategy, error preservation, and metric accuracy explicit. Standard preaggregated metrics and log-based metrics behave differently under sampling. Do not place secrets, full tokens, sensitive query strings, or unrestricted payloads in span attributes and custom dimensions.
Name operations and dependencies consistently, publish deployment markers, and keep release identity visible. Test one request across edge, application, database, queue, and worker so an operator can follow it without searching by human prose. Use live diagnostics only as a supplement to retained evidence.
Metric alerts evaluate numeric time series with aggregation, dimensions, frequency, and window. Log search alerts evaluate a KQL result and inherit query, ingestion, and scheduling behavior. Activity Log alerts respond to control-plane event categories. Choose the alert type whose data arrives quickly and reliably enough for the response objective.
Define missing-data, low-traffic, and dimension behavior. Dynamic thresholds can model established patterns, while static thresholds are often clearer for hard capacity or correctness limits. Processing rules can suppress or route alerts during planned conditions, but suppression needs scope, reason, owner, and expiry.
Action groups deliver notifications and automation. Test every receiver, authentication path, escalation, and fallback. Include impact, resource, environment, release, dashboard, and runbook in the alert context. An alert is actionable only when the recipient has authority and evidence to respond.
Azure Service Health communicates incidents, planned maintenance, health advisories, and selected service events relevant to subscriptions. Resource Health describes the state of individual supported resources. Neither replaces application telemetry: a service can be healthy while configuration or code breaks users, and a broad incident can explain several application alarms at once.
Activity Log and change analysis help identify resource configuration changes. Correlate deployment IDs, Policy remediation, role assignments, network changes, feature flags, and platform health with the first failing request. Record timestamps in UTC and preserve correlation IDs from Azure error responses.
Create dashboards for user flow, dependency health, capacity, recent changes, and recovery state rather than one crowded inventory. During an incident, move from impact to changed dependency and exact request. Afterward, convert the failure into a query, test, alert, or runbook improvement.
Azure Monitor cost can come from ingestion, retention, archive, search, export, custom metrics, managed Prometheus, availability tests, alert rules, and network movement. Attribute volume to tables and resources, remove low-value verbose data, control high-cardinality dimensions, and choose retention by operational and legal need. Do not cut audit evidence blindly.
Inject a controlled application exception, slow dependency, denied Resource Manager request, failed queue message, and broken telemetry destination. Confirm alerts, traces, KQL queries, Activity Log evidence, redaction, escalation, and retention. Test that an operator can identify the principal, release, resource, and customer impact without subscription Owner access.
After changing collection or sampling, repeat the drill. Observability is complete only when useful evidence survives the failure modes it is meant to diagnose and the team can afford to retain and query it at expected scale.
A service-level objective should use an indicator calculated from user-relevant events, such as successful eligible requests within a latency threshold. Define which requests count, which exclusions are justified, the rolling window, target, and data source. Keep the query or metric in version control and validate it against known successful and failed transactions.
An error budget is the amount of unsuccessful service allowed by the objective. Multi-window burn-rate alerts can detect both rapid exhaustion and slow sustained degradation more reliably than one static error threshold. Route a fast burn to immediate response and a slower burn to planned corrective work, with enough traffic safeguards to avoid misleading tiny samples.
Use the budget to guide release and reliability decisions rather than to punish teams or hide outages through exclusions. Review every objective after architecture, traffic, or telemetry changes, and keep a fallback signal when the primary measurement pipeline fails.
az monitor metrics list-definitions \
--resource /subscriptions/<sub-id>/resourceGroups/rg-app/providers/Microsoft.Web/sites/orders-api \
--output tableAn API intermittently times out while downstream services appear healthy in aggregate.
Constraints: Telemetry must share trace context and avoid recording secrets or request bodies.
Decision: Follow one operation ID through Application Insights dependencies, exceptions, logs, and the responsible resource metrics.
Verification: The trace identifies the slow dependency and a focused alert reproduces during a controlled delay.
Failure test: Remove trace propagation in a test deployment and confirm the observability test detects the broken chain.Expected evidence: The trace identifies the slow dependency and a focused alert reproduces during a controlled delay.Explore 500+ free tutorials across 20+ languages and frameworks.