AZ-400 Implement Continuous Feedback
The loop: read production, feed back into planning
Core / Loop
Azure Tooling
Azure Monitor
What it is
Azure Monitor is Azure’s observability service: it collects and analyzes telemetry, the evidence a system produces about what it is doing. Telemetry can be a number, a log record, an event, or a trace through an application. Azure Monitor helps people see whether a workload is healthy, investigate a problem, and notify or automate a response.
Why it exists
Every resource generates telemetry, but raw data is useless. You need a central place to (1) collect telemetry, (2) store it durably, (3) query/visualize it, and (4) react when something is wrong. Without Azure Monitor you’d have hundreds of disconnected portals per resource.
Key ideas
- Metrics are numeric measurements over time, such as CPU percentage or request count. Use them to spot trends and quick threshold conditions.
- Logs are richer records that you query, commonly in a Log Analytics workspace with KQL. Use them to investigate “which request failed and why?”
- The Activity log records Azure management events, such as someone creating or deleting a resource. It is not the same as an application’s request log.
- Application Insights adds application-level telemetry such as requests, dependencies, exceptions, and traces.
- An alert evaluates a signal and can invoke an action group to notify people or trigger a workflow. A dashboard or workbook helps people explore the data; it does not fix the issue itself.
Northwind example
Northwind uses Azure Monitor to watch its ordering workload. A metric shows that front-end CPU is rising, Application Insights shows that checkout requests are failing after a storage dependency call, and the Activity log shows a network-rule change shortly before the failures. An alert sends the on-call team a notification through an action group. The metric tells Northwind that something changed; the logs and traces help it discover why.
Common confusion
- Azure Monitor is the umbrella service, not a single log file or dashboard.
- Collecting data is not the same as retaining it forever. Configure data collection, destination, retention, access, and cost intentionally.
- An alert is a detector. An action group is the recipient or automation it invokes. Neither replaces an incident-response plan.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/overview
Start small
Begin with the user-facing success signal, a few resource-health metrics, a destination for useful logs, and an alert that reaches a real owner. Test the alert and its action before relying on it in an incident. Add more telemetry only when it answers a decision or troubleshooting question.
Related
azure-monitor-metrics · azure-monitor-activity-log · log-analytics · kql · metric-alert · action-group · workbooks · application-insights · northwind-traders-case-study
📘 Source: Microsoft Learn — Azure Monitor overview, checked 2026-09-16.
Application Insights
What it is
Application Insights is Azure Monitor’s application-performance-monitoring feature. It collects evidence from inside a running application—requests, dependencies, exceptions, traces, and selected user interactions—so a team can understand what customers experienced rather than only what a server did.
Why it exists
Infrastructure monitoring (CPU, disk) tells you the host is fine but not why users are frustrated. Application Insights instruments the app itself to reveal request latency, error rates, failed dependencies (DBs, external APIs), and end-to-end distributed traces — the insight you need for debugging performance.
Key ideas
- Instrumentation sends application telemetry to Application Insights. For many code-based server applications, Microsoft recommends OpenTelemetry-based collection; the exact setup depends on the runtime.
- A request is work the application receives. A dependency is an external call it makes, such as to storage or a database. An exception records an error. A trace supplies diagnostic context across those operations.
- Application Map and transaction views can show how components call each other. Log Analytics and KQL support deeper analysis where configured.
- Availability tests check an endpoint from outside the application. They are useful evidence of reachability, but do not prove every user journey or dependency works.
Northwind example
When a shopper cannot submit an order, Northwind looks in Application Insights. It can see the failed checkout request, the slow call to Blob Storage, the exception message, and correlated telemetry from the same transaction. A VM CPU metric alone could show that the VM was healthy while customers still saw an application error.
Common confusion
- Application Insights is not a substitute for Azure Monitor infrastructure monitoring; it is part of that wider platform.
- Instrumentation can collect sensitive information if configured carelessly. Choose what to collect, scrub sensitive fields, limit access, and set appropriate retention.
- A successful availability test does not prove a logged-in checkout, payment, or data path is working.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: azure-monitor/app/app-insights-overview
Where it appears in the route
Read azure-monitor first, then connect this entry to log-analytics, kql, alerts, and an application deployment.
Related
azure-monitor · log-analytics · kql · metric-alert · workbooks · northwind-traders-case-study
📘 Source: Microsoft Learn — Application Insights OpenTelemetry observability, checked 2026-09-16.
User & Reliability Signals