Azure Monitor & Log Analytics

The job can fail while nobody is awake. Azure Monitor can collect several kinds of telemetry, but start with two. Platform metrics are numeric measurements such as request count or CPU use; Azure collects supported metrics automatically in its metric store, where Metrics Explorer can chart them. Resource logs are detailed event records such as a failed request. They reach a Log Analytics workspace only after you configure collection for that resource. Neither a metric nor a log sends a person a warning by itself; that requires an alert rule.¹

Metric vs log

A metric measures a quantity over time; a log records an event and its fields. Either can support an alert or an investigation, depending on what data exists and the question you ask.

Ask "Is the storefront slow?" and a latency metric may answer quickly. Ask "Which store's upload failed, and what error did it return?" and you need an event record with those fields. First check that the application actually writes the detail you need, then that its collection route exists. Logs cannot explain an error the application never recorded.

Azure collects supported platform metrics automatically into its metric store. Resource logs are different: choose supported categories and create a diagnostic setting to route them to a workspace or another destination. A setting created today does not backfill yesterday's resource logs. The subscription Activity Log is a separate exception: Azure collects management events automatically and retains them for 90 days, even without a workspace setting.²

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

# open the valve on the storage account's blob service
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)/blobServices/default" \
  --workspace $(az monitor log-analytics workspace show \
      -g rg-campux-platform -n campux-logs --query id -o tsv) \
  --logs '[{"category":"StorageWrite","enabled":true}]'

One storage-specific wrinkle in that command teaches a general lesson: the valve sits on the blobServices/default sub-resource, not the account. A storage account at top level emits only metrics; the read-and-write logs live on the services inside it — blob, file, queue, table — each with its own valve. Point the setting at the account and Azure refuses the category; point it at the service and the logs flow. Most resources are simpler than this, but the habit transfers: check which resource actually emits the category you want before wondering why the workspace is empty.

Opening settings one resource at a time is easy to forget. Azure Policy's DeployIfNotExists effect can deploy diagnostic settings for supported resource types in the policy's scope. It needs a managed identity with permission, and existing resources may need a remediation task. Policy evaluation is not instantaneous. Check compliance and query for fresh rows before claiming coverage; an assignment alone is not proof that every log is arriving.

Routed logs can land in a Log Analytics workspace, in typed tables you query with KQL next class. Start by considering a shared workspace for related workloads, then test access, region, retention, and cost requirements before deciding whether to split:

Consider one

A shared workspace makes cross-service investigations easier when relevant records are collected, compatible, and accessible to the investigator. A common destination alone does not guarantee a useful join.

Split for a named requirement

Region and residency, access boundaries, retention, operational ownership, or a billing model that shared attribution cannot meet are reasons to consider more than one workspace. Document the query cost of a split.

Test access explicitly

Resource-context access and Azure RBAC can scope many queries, but workspace permissions and table access matter too. Verify a test identity can read only the intended records before putting sensitive teams together.

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.

For many Log Analytics tables, ingestion volume and retention affect the bill. The charge depends on table plan, data source, and current Azure pricing; the subscription Activity Log and platform metrics follow different rules. Verbose resource-log categories can create significant volume. Retention decides how long a table remains available for normal queries and, where supported, how long it remains in long-term storage. Check the current plan and price of each table before changing its settings.³

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. There is also a middle path between full price and silence: every table carries a plan, and moving a verbose, low-value table from the default Analytics plan to Basic or Auxiliary cuts its ingestion price sharply in exchange for limited querying and short retention. Half of every real workspace cost conversation now happens at the table-plan level, and Class Thirty-Two will lean on it. 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" calls for evidence, not a product list. Describe three checks. Coverage: identify the resources and failure modes that matter, configure supported collection, and verify fresh data arrives. Access: keep related records queryable by the people who investigate while honoring region and security requirements. Response: test alerts and triage, then check for gaps before incidents find them. Policy helps with repeatable settings, but it does not prove telemetry or notification by itself.

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.