Kladde.Verlauf now runs in two regions, without keys, regulated in the network. Whether it runs well, nobody says yet. This lesson settles what you see: which figures are there anyway, which ones you have to switch on, how to tell a 429 from a hot partition, and what may trigger an alert at night.
Prior knowledge. Application Insights, KQL and alerts are in "K3, Lesson 3.4.2", "3.4.4" and "3.4.5" and are not repeated (when an alarm is actionable is stated there). The SDK's diagnostics object is in Lesson 1.2, the figures on the offices and the hot partition in Lesson 1.4.
What was run. The Bicep file was compiled with az bicep build; a C# program (.NET 10) calculates the hot-partition example. The KQL queries were not run: there was no workspace. Table and column names come from Learn's reference pages, not from a run. Not run against Azure is everything that needs data from an account. The load in the example is invented.
Three sources
| Source | Active? | Granularity | What for |
|---|---|---|---|
| Metrics (Azure Monitor) | without any action | one minute, precomputed | overview, alerts |
| Diagnostic logs (Log Analytics) | diagnostic setting needed | per request | cause, expensive queries, keys |
Activity log and ControlPlaneRequests |
management plane (switch in Lesson 3.1) | per operation | who changed what on the account |
Learn contrasts metrics (fast, but coarse) with logs (per request, with storage costs). Cost driver: ingestion and retention in the workspace (K3, Lesson 3.4.2). The diagnostic logs are therefore a decision, not a default.