Azure Monitor & Log Analytics

Everything you have built now runs without you: the pipeline deploys at merge, the job fires at 02:00, the app scales itself to zero and back. Automation's price is ignorance — nobody is watching, so nobody knows. Azure Monitor is the umbrella name for Azure's answer, and its telemetry comes in two shapes worth keeping strictly separate in your head. Metrics are numbers: CPU at 61 percent, 340 requests per minute, queue depth 12 — cheap to collect, sampled constantly, perfect for charts and thresholds. Logs are sentences: "02:04:11 — job pos-batch-job execution failed: connection to store 23 timed out" — rich, structured records of what happened, queryable like a database.¹

Metric vs log

A metric is a number sampled over time — it tells you that something is happening and how much. A log is a recorded event with details — it tells you what happened and why. Dashboards and alerts run on metrics; investigations run on logs.

The two shapes answer different questions, and mixing them up wastes both. "Is the storefront slow right now?" is a metric question — one glance at a chart. "Why did store 23's upload fail last Tuesday?" is a log question — no chart will ever contain the answer, but a query over the job's log records will. Metrics are the smoke detector; logs are the security-camera footage. You need both, they are collected differently, and — the fact the whole next section turns on — only one of them shows up without being asked.

Here is the surprise that finds every Azure engineer eventually, usually mid-incident. Platform metrics flow automatically — create a storage account and its charts are simply there. Resource logs do not. Every Azure resource is willing to narrate its life in detail — every blob read, every firewall denial, every job execution — but that narration is thrown away by default. It reaches a workspace only if you create a diagnostic setting on the resource: a small routing rule that says these log categories go there. No setting, no history. And the cruelty of the default is its timing: you discover the logs are missing at the exact moment you need them, and no setting created today can recover last night.²

The setting itself is small — a name, the log categories to route, and the destination workspace:

# open the valve on the storage account
az monitor diagnostic-settings create \
  --name send-to-campux-logs \
  --resource $(az storage account show -g rg-campux-platform \
      -n campuxstorage --query id -o tsv) \
  --workspace $(az monitor log-analytics workspace show \
      -g rg-campux-platform -n campux-logs --query id -o tsv) \
  --logs '[{"categoryGroup":"audit","enabled":true}]'

Because the valve must be opened per resource, the real engineering question is how to guarantee it is never forgotten — and you already own the answer. Class Eight's Azure Policy can require diagnostic settings on every resource of a given type, and its DeployIfNotExists effect can create them automatically the moment a resource is born. The valve stops being a checklist item humans forget and becomes a law of the subscription. That policy assignment is this class's case file, and it is the difference between "we log what we remembered to log" and "we log, full stop."

Where do all those routed logs land? A Log Analytics workspace: the reservoir at the end of the plumbing, storing records in typed tables you will query with KQL next class. The design question every organisation faces is deceptively simple — one workspace, or many? — and the modern default is emphatic:

Start with one

A single central workspace means every investigation happens in one place — the storage account's denials and the job's failures in the same query, joined. Correlation is the entire point of centralised logging, and every extra workspace is a wall through the middle of it.

Split only for a named reason

Data residency (logs that legally must stay in a region), hard billing separation between business units, or a genuinely separate security boundary. These are real reasons; "each team wanted its own" is not — access control has a better answer.

Scope access, not storage

The fear behind workspace sprawl is "team A should not read team B's logs" — solved by resource-context access: users with RBAC on a resource can query that resource's logs in the central workspace without seeing anyone else's. Class Eight, again, doing the work people try to do with architecture.

The anti-pattern has a recognisable shape: eleven workspaces, one per team, created over three years — and then an incident that spans two of them, and an engineer at 3am writing the same query twice and correlating timestamps by hand in a text editor. Fragmented logging converts every cross-cutting investigation into an archaeology project. One reservoir, well-governed, beats eleven puddles.

The workspace bills like a reservoir: you pay for what flows in, and you pay for how long you keep it. Ingestion — billed per gigabyte — is usually the dominant cost, and it is set by the §2 valves: every log category you route is a running tap, and verbose categories (every blob read on a busy storage account, say) can pour surprising volumes. Retention is the second dial: how long records stay queryable. Interactive retention — the period you can query normally — comes with a default measured in weeks, extendable for a fee; beyond it, long-term retention keeps data for up to twelve years at low cost, retrievable when an auditor or a lawyer asks, but not sitting in your everyday queries.³

You cannot query the logs you never kept.

The discipline is to make both dials deliberate, per table, because the failure modes sit on both sides. Keep everything hot forever and monitoring quietly becomes a top-five line item — the Class Thirty-Two FinOps review will find it. Keep too little and you meet §2's cruelty in a new costume: the breach investigation that needs ninety days of sign-in history in a workspace that kept thirty. Security-relevant tables (sign-ins, audit, firewall) earn long retention; chatty debug categories earn short retention or a closed valve. The question to ask of every table is the same one Class Twelve asked of every storage tier: who needs this data, how old, and how fast? Price the answer, and write it down.

"Tell me about your monitoring" is a standard interview prompt, and the weak answer lists products — "we had Azure Monitor and some dashboards." The strong answer describes a posture, and it has three legs. Coverage: telemetry flows from everything, by policy rather than memory — the §2 valve opened by law, so there is no resource whose failure would be invisible. A place: one workspace where signals meet, so a question that spans three services is one query, not three tabs. A habit: somebody actually looks — dashboards reviewed, alerts triaged (Class Thirty's subject), and the monitoring itself checked for gaps before incidents find them.

Notice what the posture is for. Monitoring does not prevent failures — the job will still break some night, disks will still fill, certificates will still expire. What it changes is the shape of the morning after: the difference between "the job failed at 02:04, at the connection to store 23, here is the record" and "the job apparently hasn't run for nine days and nobody can say why." Class One's outage took nine hours partly because diagnosis started from nothing. The posture you build this class is what makes sure no Campux investigation ever starts from nothing again — and being able to say that sentence, with the policy assignment to back it, is worth more in an interview than naming every product in the Azure Monitor family.