Implement an instrumentation strategy
DevOps Monitoring Configuration
CoreConfigure application and resource telemetry, integrate deployment and pipeline events, and route actionable failure alerts through Azure Monitor, GitHub, and Azure Pipelines.
Aligned to AZ-400 skills measured as of July 27, 2026; guide and product behavior verified September 25, 2026.
Why this matters
Monitoring begins with collection and correlation, not a dashboard. The right insight depends on resource type, identity, workspace, sampling, diagnostic settings, and event routing.
Must Know
- Azure Monitor metrics are time-series values; Azure Monitor Logs stores queryable records in Log Analytics workspaces; alerts can evaluate either signal type.
- Application Insights collects application requests, dependencies, exceptions, traces, availability, and metrics through supported instrumentation such as OpenTelemetry.
- VM Insights, Container Insights, Azure Monitor for Storage, and Azure Monitor for Networks provide resource-specific views and collection requirements.
- Deployment markers or stable release identifiers let teams correlate changes with application and infrastructure behavior.
- GitHub Actions provides run history, visualization, logs, execution time, status badges, and notifications; repository or project insights use consistently maintained metadata.
- Azure DevOps notifications can target build or release events; subscriptions should narrow project, pipeline, outcome, and recipient.
- External incident or work-item integrations should validate requests, avoid secret leakage, and deduplicate retries.
Compare and Distinguish
- Metrics are efficient numeric time series; logs carry detailed records and dimensions; traces correlate operations across services.
- An insight is a curated monitoring experience; a diagnostic setting or agent supplies data; an alert evaluates a signal.
Scenario examples
- Scenario: Container nodes show pressure but application requests look normal. Think: Container Insights and infrastructure metrics alongside Application Insights.
- Scenario: Only failed production workflows should page on-call. Think: scoped failure subscriptions and idempotent incident creation.
Exam traps
- Creating a workbook does not enable telemetry collection.
- Application Insights alone does not supply every host, network, storage, or Kubernetes platform signal.
- Alerting on every failed retry can create incident storms without new information.
Key takeaways
- Select the signal and collection path before choosing a visualization.
- Carry release identity into telemetry.
- Route only actionable events and deduplicate automation.
How it works
- Agents, SDKs, platform diagnostics, and resource integrations send signals to Azure Monitor stores where queries and alerts evaluate them.
- An idempotent incident receiver uses stable condition identity to update retries and opens a new record only after resolution.
Objects and administrative surfaces
- Azure Monitor Metrics, Log Analytics, Application Insights, Insights experiences, workbooks, alert rules, action groups, and diagnostic settings.
- GitHub Actions run pages, workflow logs, Insights, Projects charts, notifications, and webhooks.
- Azure Pipelines Analytics, run logs, dashboards, and notification subscriptions.
When to use it
- Use Container insights when failures depend on pod, node, controller, or cluster state that request instrumentation cannot see.
Security and governance implications
- Protect action credentials, limit alert destinations, and avoid placing sensitive payload data in broadly visible work items or chat.
Troubleshooting signals
- For a missing alert, follow collection, ingestion delay, query window, threshold, evaluation frequency, action status, and receiver deduplication.
More detail
- Carry a stable release identifier into deployment events so charts and incident investigations can locate the exact change.
- Use resource-specific Azure Monitor integrations instead of assuming application instrumentation captures node, pod, storage, and network state.
- Design failure notifications by event, workflow, environment, destination, deduplication key, and resolution behavior.
Ready for the quiz?
- Which service supplies distributed application telemetry?
- What creates a link between a deployment and a performance regression?
- Why can an alert rule return no data even when a dashboard exists?
Related objectives
- D5.1.S1 — Configure Azure Monitor and Azure Monitor Logs to integrate with DevOps tools
- D5.1.S2 — Configure collection of telemetry by using Azure Monitor Application Insights, Azure VM Insights, Azure Container Insights, Azure Monitor for Storage, and Azure Monitor for Networks
- D5.1.S3 — Configure monitoring in GitHub, including enabling insights and creating and configuring charts
- D5.1.S4 — Configure alerts for events in GitHub Actions and Azure Pipelines