Contoso Airlines today has a platform spread across web applications, an API on a scale set, containers, ephemeral functions, queues, topics, databases and AI services. When something goes wrong, the question is no longer "is the server down?", it is "which part of this chain is failing, since when, for how many passengers and why". Answering that requires the system to emit information and for somebody to have collected it before the problem happened. That is the discipline this module opens with.

This lesson is the map. You are going to understand what observability is and its three signals, how Azure Monitor gathers them all under a single umbrella, how platform metrics are configured along with the piece almost everybody forgets — the diagnostic setting — and how to build an alerting system that wakes somebody up only when it is worth it. All of it on Contoso's real resources.

1. Observability: three signals, not a CPU alert
2. Azure Monitor as an umbrella
3. Platform metrics and the metrics explorer
4. Diagnostic settings: the forgotten piece
5. Activity log, resource logs and operating system logs
6. Alerts: types, conditions and thresholds
7. Action groups and processing rules
8. Contoso's alert set
9. SLI, SLO and error budget
10. Dashboards and workbooks
11. The cost of monitoring
12. Common Mistakes and Tips
13. Exercises
14. Conclusion

Monitoring is checking that a set of known indicators stays within range. Observability is the property of a system that lets you answer questions nobody had anticipated, without deploying new code. The difference matters: an alert on CPU at 90% is monitoring, and it would have said absolutely nothing about the passenger who paid and never received their boarding pass.

The three classic signals:

The practical rule: metrics detect, logs explain, traces locate. A system that only has metrics knows something is wrong and does not know what. One that only has logs pays a fortune and searches blind. Contoso needs all three, and each one has its own lesson in this module.

Azure Monitor is not a product: it is the name of the whole collection. It pays to see the full map from the start, so you know where each lesson fits.

Three ideas from the diagram: there are two data platforms — metrics and logs — with different prices, retentions and query languages; data does not arrive on its own in the logs, you need a diagnostic setting or an agent, and that is the most frequent oversight; and the Insights (Application, Container, VM) are not separate stores but visual experiences built on top of those very same data.

Platform metrics are emitted by Azure automatically, with nothing to configure and at no cost, for almost every resource. Their properties:

• One-minute granularity on most resources, aggregated afterwards into larger intervals.
• 93-day retention. After that they disappear, unless you export them to Log Analytics.
• Dimensions: attributes that let you break a metric down. An App Service's Http5xx can be split by instance; Storage requests, by API type or by response code.
• Aggregations: average, minimum, maximum, total and count. Picking the wrong aggregation is the classic mistake — an hour's average latency hides the spike that angered the passengers.

Query the response time of the bookings website from the CLI:

• --metric accepts several metrics at once; the names are the internal ones, not the portal's. To discover them: az monitor metrics list-definitions --resource "$APP_ID".
• --interval PT5M is ISO 8601 duration notation: 5 minutes. PT1H would be one hour.
• --aggregation asks for all three aggregations so you can compare average and maximum in the same table.

In the portal, the metrics explorer does the same thing visually: you pick a resource, a metric and an aggregation, and add a split by dimension. Marta Ríos' typical flow when a slowness complaint comes in is: HttpResponseTime as an average and as a percentile, split by instance. If a single instance is slow, it is a problem with that instance; if all of them are, the problem is further back — usually in sql-contoso-reservas-pro.

Platform metrics exist on their own. Resource logs do not. An App Service sends its HTTP logs nowhere, nor does SQL Database send its slow queries, nor Key Vault who accessed what, until you create a diagnostic setting that says which categories are exported and where to. It is common to discover this on the day of the incident, when it is already too late: logs do not exist retroactively.

Each resource type publishes its own categories. Real examples:

And three possible destinations, which can be combined:

Create the diagnostic setting for the bookings website:

Two parameters deserve attention. --export-to-resource-specific true makes the data land in dedicated tables (AppServiceHTTPLogs) instead of in the generic AzureDiagnostics table; it is a better schema, better performance and it allows different table plans, and you will make use of it in 07-02. --metrics AllMetrics duplicates the platform metrics into the logs: useful for correlating and for keeping them beyond 93 days, but it is ingestion you pay for, so switch it on only where you need it.

Doing this resource by resource does not scale. That is why Contoso already has, inside the "Base de gobernanza de Contoso" initiative from module 4, the diagnostico-app-service assignment with a DeployIfNotExists effect: any new App Service automatically gets its setting pointing at log-contoso-pro. Compliance is checked with az policy state summarize --resource-group rg-contoso-reservas-pro. Policy is what turns "remember to switch diagnostics on" into a guarantee. Remember that DeployIfNotExists only acts on new resources, or when you run a remediation task over the existing ones.

Three layers that get confused constantly:

The activity log always answers the question "what changed just before it broke?", which resolves a notable share of incidents:

For virtual machines, the Azure Monitor Agent replaces the old agents and does not decide on its own what to collect: that is determined by a data collection rule (DCR), an independent, reusable resource that states which sources are read, how they are transformed and which workspace they go to. That separation lets you change the collection on a hundred machines by editing a single object: you create the dcr-contoso-servidores DCR once and associate it with each machine using az monitor data-collection rule association create.

A cost detail with consequences: a badly filtered DCR that collects all the syslog from a chatty server can cost more than the virtual machine itself. DCRs support KQL transformations at ingestion time so you can discard the irrelevant before paying for it; we will come back to that in 07-02.

An alert is a rule that evaluates a data source and, if the condition is met, fires an action group. The available types:

The service health and resource health ones are free and almost nobody configures them, even though they are the ones that tell "we broke something" apart from "Azure has a problem in the region". Always set them up.

On thresholds:

• Static: you set the number. Predictable and auditable. Right when there is a commitment — the SLO says 800 ms, you alert at 800 ms.
• Dynamic: Azure learns the historical pattern, including daily and weekly seasonality, and alerts on deviations. Ideal for metrics with a natural cycle: traffic to app-contoso-reservas-pro falls overnight, and a static threshold of "fewer than 100 requests per minute" would fire every night.

Two parameters govern the noise: the evaluation frequency (how often it is checked) and the aggregation window (how much time is aggregated on each check). Evaluating every minute over a one-minute window fires on any transient spike. Contoso uses evaluation every 5 minutes with a 15-minute window for latency, and every minute with a 5-minute window for availability.

An action group is the list of who gets notified and what gets run. You define it once and reuse it across every rule.

• --short-name (12 characters maximum) is what appears as the sender on the SMS.
• useCommonAlertSchema forces the common alert schema, a JSON payload with the same shape for every type. Without it, each alert type sends a different payload and the consumer becomes unmaintainable. Always switch it on.

The available action types: email, SMS, push notification, voice call, email to an Azure Resource Manager role, webhook, secure webhook with Entra ID, Logic App, Azure Function, Automation runbook and ITSM connector. Contoso uses three groups:

Alert processing rules act on alerts that have already been generated, without touching the rules. They serve two purposes: suppressing during a maintenance window and adding an action group to a set of alerts in one go.

Without this, on the night of the monthly deployment the team gets forty text messages, and by the third time somebody silences the on-call phone permanently. Noise is not an annoyance: it is how an alerting system dies.

This is the actual table Marta maintains, and its value lies as much in what it contains as in what it deliberately does not.

Notice what is not there: no CPU alert, no memory alert, no application disk alert. Not because they do not matter, but because they are causes, not symptoms. CPU at 95% with latency inside the target and no errors is not a problem: it is a well-used machine. Alerting on causes produces pointless wake-ups and, worse, trains the team to ignore the phone. You alert on what the passenger notices; causes are investigated afterwards, with metrics and logs, which is what they are for.

A metric rule via the CLI, to set the pattern (the mandatory tags apply here too: an alert rule is a billable resource and must be attributed to CC-1042):

Without these three concepts, thresholds get picked by intuition and argued about forever.

• SLI (service level indicator): the concrete measurement. "Percentage of requests to /api/disponibilidad answered successfully in under 800 ms."
• SLO (service level objective): the value you commit to. "99.5% monthly."
• Error budget: what the SLO allows you to fail. 99.5% monthly is 3 hours and 39 minutes of non-compliance.

The error budget turns an argument about opinions into one about arithmetic: if 70% has been consumed in the first week, risky changes get frozen and the effort goes to reliability; if there is budget left at the end of the month, you deploy more cheerfully. And it answers the awkward question Nuria Peña will ask in module 8: going from 99.5% to 99.99% does not cost a little more, it costs multiplying the infrastructure.

Two tools that look alike and are not the same thing:

Contoso's operations dashboard lives on a screen in the control center and shows six tiles: health endpoint availability, requests per minute and p95 latency for the API, 5xx errors on the website, cola-emision-tarjetas depth, db-reservas DTU and active alerts by severity. Nothing more: nobody looks at a dashboard with thirty charts. The parameterized workbook "Bookings Health" is the investigation tool instead, with three parameters — time range, environment and booking reference — that fill in the KQL queries of the next lesson; the same template serves production and development by changing a dropdown, and it is versioned in the contoso-infra repository alongside the Bicep templates. The availability tests that feed the first alert in the table belong to Application Insights and are explained in 07-03.

A warning worth internalizing now, even though the detail arrives in 07-02: data ingestion and retention in Log Analytics is one of the Azure bills that surprises people most. Nothing warns you that you left debug logging switched on in production; it is simply that at the end of the month the Log Analytics line is the biggest one in the subscription. Contoso lived through it: switching on AppServiceConsoleLogs across all four applications during an investigation and forgetting to switch it off cost more than the App Service plan that generated it.

Two practical consequences: a log alert evaluated every minute across fifty resources is a considerable bill, so tune the frequency to what you genuinely need to detect; and alerts targeting SMS are best reserved for severity 0 and 1, which is exactly what ag-guardia-contoso does.

• Believing logs exist without a diagnostic setting. On the day of the incident you discover there is nothing, and logs do not appear retroactively. Switch them on with policy, not by hand.
• Alerting on causes. CPU, memory and disk generate noise; alert on symptoms visible to the passenger.
• Picking the wrong aggregation. The average hides the spikes. For latency, percentiles; for errors, totals.
• Not configuring the free alerts. Service health and resource health cost nothing and save you an hour investigating a problem that is Azure's.
• Evaluation windows that are too short, or maintenance without suppression. Both produce predictable noise, and noise kills the system's credibility: use alert processing rules.
• Tip: define the SLO before the threshold. If you do not know what you promised, any number is debatable.
• Tip: every alert must carry a link to its runbook in the description; an alert at 3 in the morning with no instructions is half an alert. And review quarterly which ones fired and what was done about them: the ones that never led to an action get deleted.

Exercise 1. Contoso wants to keep an eye on the new public "Contoso Miles" API (centro-coste=CC-2077), deployed on an App Service in rg-contoso-reservas-dev. Define: which signals you would switch on, with what diagnostic setting, three alerts with their severity and action group, and one justified cost decision.

Exercise 2. Over two weeks the team has received 340 alerts and has acted on 6. Analyze what is going on, propose four concrete measures and explain the risk of doing nothing.

Exercise 3. The business asks for a 99.99% availability SLO on db-reservas. Calculate the monthly error budget, state what it implies technically and what counterproposal you would make.

Solution 1:

• Signals and diagnostics: platform metrics (free, they already exist); resource logs via a diagnostic setting with AppServiceHTTPLogs and AppServiceAppLogs — not AppServiceConsoleLogs, which is the one that blows up the bill — into log-contoso-pro with --export-to-resource-specific true and a short retention because this is a trial; and traces with Application Insights (07-03). If the diagnostico-app-service assignment reaches rg-contoso-reservas-dev, the setting deploys itself: it is worth verifying.
• Alerts: (1) resource health, severity 1, ag-guardia-contoso, free; (2) Http5xx > 25 in 5 min, severity 2, ag-equipo-contoso, because a side project does not justify waking anybody up; (3) HttpResponseTime with a dynamic threshold, severity 3, ag-registro-contoso, because there is no known baseline yet.
• Cost: email notifications, no SMS, and evaluation every 15 minutes instead of every minute. Tags entorno=desarrollo, proyecto=contoso-millas, centro-coste=CC-2077, propietario.

Solution 2: the ratio is 1 action for every 57 notifications: the system has stopped being informative and the team has already learned to ignore it. The usual causes: alerts on causes (CPU, memory), one-minute evaluation windows that capture transient spikes, no suppression during deployments and maintenance, and a single incident firing ten rules at once. Measures: (1) delete every alert that has not led to an action in three months; (2) widen aggregation windows to 15 minutes on noisy metrics and move to dynamic thresholds where there is seasonality; (3) create alert processing rules for the deployment and maintenance windows; (4) reassign severities so that only 0 and 1 use SMS, leaving the rest on email or an incident record. The risk of not acting is concrete: the next real outage will arrive as notification number 341 and nobody will look at it.

Solution 3: 99.99% monthly leaves 4 minutes and 23 seconds of error budget per month — less than a manual failover takes. Technically it implies automatic failover with fg-contoso-reservas, a service tier with the corresponding SLA, zone redundancy, retries with reconnection logic in the application and zero-downtime deployments, on top of the fact that Azure's SLA for a single logical server is no longer enough. A reasonable counterproposal: 99.95% for the database (21 minutes and 54 seconds of budget) combined with an experience SLO — "the passenger can look up their booking" — backed by a read-only cache during the failover. It costs a fraction and it protects what the business actually values. And, on top of that, the commitment has to be measured against an agreed SLI, not against the availability the provider declares.

You now have the full map. You know that observability rests on three signals — metrics to detect, logs to explain, traces to locate — and that Azure Monitor is the umbrella covering the two data platforms, the Insights experiences and consumption through alerts, workbooks and dashboards. You know platform metrics: free, with one-minute granularity and 93 days of retention, their dimensions and aggregations, and how to explore them on app-contoso-reservas-pro. And above all, you have mastered the piece almost everybody forgets: the diagnostic setting, its categories per resource type, its three destinations and its deployment at scale through the diagnostico-app-service assignment with DeployIfNotExists.

You can tell the activity log — who changed what — from resource logs and from operating system logs, collected by the Azure Monitor Agent with its data collection rules. You have seen the five alert types, including the free ones almost nobody switches on, static versus dynamic thresholds and the role of the evaluation frequency; you have created ag-guardia-contoso with the common alert schema and you know how to suppress maintenance with processing rules. Contoso's alert set has taught you the rule that holds everything else up — alert on symptoms, never on causes — with SLI, SLO and error budget as the criterion for choosing thresholds instead of arguing about them, and with dashboards and parameterized workbooks as the query surface. And you carry the cost warning: platform metrics and alerts are almost free, text messages are charged for, and log ingestion is the line item that catches you out.

That is exactly where the next lesson goes. Everything you sent with the diagnostic settings has landed in log-contoso-pro, and so far you have only stored it. In 07-02, Log Analytics and KQL Queries, you will learn to interrogate it: the tables you are going to find, the KQL language from scratch and explained line by line, the full journey to investigate the complaint from the passenger who paid and never got their boarding pass, and the three levers — what gets ingested, on which plan and for how long it is kept — that control the bill we have just announced.