Kladde.Verlauf läuft nun in zwei Regionen, ohne Schlüssel, im Netz geregelt. Ob es gut läuft, sagt noch niemand. Diese Lektion legt fest, was man sieht: welche Zahlen ohnehin da sind, welche man einschalten muss, wie man ein 429 von einer heißen Partition unterscheidet und was nachts eine Warnung auslösen darf.
Vorwissen. Application Insights, KQL und Warnungen stehen in „K3, Lektion 3.4.2", „3.4.4" und „3.4.5" und werden nicht wiederholt (wann ein Alarm handlungsfähig ist, steht dort). Das Diagnoseobjekt des SDK steht in Lektion 1.2, die Zahlen zu den Büros und zur heißen Partition in Lektion 1.4.
Was ausgeführt wurde. Die Bicep-Datei wurde mit az bicep build übersetzt; ein C#-Programm (.NET 10) rechnet das Beispiel zur heißen Partition. Die KQL-Abfragen wurden nicht ausgeführt: Es gab keinen Arbeitsbereich. Tabellen- und Spaltennamen stammen aus Learns Referenzseiten, nicht aus einem Lauf. Nicht gegen Azure ausgeführt ist alles, was Daten aus einem Konto braucht. Die Last im Beispiel ist erfunden.
Drei Quellen
| Quelle | Aktiv? | Körnung | Wofür |
|---|---|---|---|
| Metriken (Azure Monitor) | ohne Zutun | eine Minute, vorberechnet | Überblick, Warnungen |
| Diagnoseprotokolle (Log Analytics) | Diagnoseeinstellung nötig | je Anfrage | Ursache, teure Abfragen, Schlüssel |
Aktivitätsprotokoll und ControlPlaneRequests |
Verwaltungsebene (Schalter in Lektion 3.1) | je Vorgang | wer hat was am Konto geändert |
Learn stellt Metriken (schnell, aber grob) und Protokolle (je Anfrage, mit Speicherkosten) gegenüber. Kostentreiber: Aufnahme und Aufbewahrung im Arbeitsbereich (K3, Lektion 3.4.2). Die Diagnoseprotokolle sind daher eine Entscheidung, keine Voreinstellung.