Microsoft AZ-204: Azure-Überwachung, Diagnose und DevOps-Integration — Lernleitfaden

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Teil des Microsoft Azure Developer Associate AZ-204 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Azure Monitor und Application Insights bieten einen einheitlichen, entwicklerorientierten Observability-Stack für Azure-Anwendungen. Application Insights sammelt Anwendungs-Telemetriedaten wie Anfragen, Abhängigkeiten, Ausnahmen und Ablaufverfolgungen, während Azure Monitor Metriken und Protokolle über Ressourcen hinweg in einem Log Analytics-Arbeitsbereich aggregiert und für Warnungen und DevOps-Integrationen zuständig ist. Die Beherrschung von Instrumentierungsoptionen, Telemetrie-Semantik, Verfügbarkeitstests, der Kusto Query Language (KQL), Warnungen mit Aktionsgruppen, verteilter Ablaufverfolgung und Infrastructure as Code mit ARM-Vorlagen gewährleistet zuverlässige, diagnostizierbare und automatisierbare Lösungen.

Application Insights-Instrumentierung und -Telemetrie

Application Insights-Ressourcen werden für die Erfassung entweder durch einen Instrumentierungsschlüssel oder eine Verbindungszeichenfolge identifiziert. Der Instrumentierungsschlüssel ist die veraltete, einzelne GUID, die von SDKs zum Weiterleiten von Telemetriedaten verwendet wird. Die Verbindungszeichenfolge ist die aktuelle Empfehlung; sie enthält den Instrumentierungsschlüssel sowie Endpunkt-Metadaten (Erfassungs- und Live Metrics-Endpunkte) und ermöglicht das Routing zu nicht standardmäßigen Endpunkten (für Sovereign- oder private Clouds). Verwenden Sie die Verbindungszeichenfolge in neuem Code und neuer Konfiguration; sie ermöglicht zukünftige Änderungen an Endpunkten ohne erneute Code-Bereitstellungen. Innerhalb eines App Service füllt die Aktivierung von Application Insights auf Plattformebene die Verbindungszeichenfolge in die Umgebungseinstellungen für automatisch erkannte Runtimes ein.

Die Instrumentierung kann über ein SDK oder durch Auto-Instrumentierung erfolgen. Der SDK-Ansatz (z. B. Microsoft.ApplicationInsights.AspNetCore für .NET, applicationinsights für Node.js und der Application Insights Java Agent) bietet Kontrolle auf Code-Ebene: benutzerdefinierte Ereignisse, Metriken und angereicherte Telemetrie über TelemetryInitializers und Prozessoren, einschließlich adaptiver Stichprobenentnahme (Adaptive Sampling). Die Auto-Instrumentierung (codefreie Anbindung, Codeless Attach) ist für App Service und einige Compute-Stacks verfügbar und verwendet Site-Erweiterungen/Agenten, um eingehende Anfragen, Abhängigkeiten und Ausnahmen ohne Code-Änderungen zu erfassen. Verwenden Sie die SDK-Instrumentierung, wenn Sie benutzerdefinierte Ereignisse, Geschäftsmetriken oder eine explizite Korrelation in Hintergrundjobs benötigen; verwenden Sie die codefreie Anbindung für schnelle, aufwandsarme Einblicke oder für Lift-and-Shift-Workloads. In beiden Fällen sollten Sie den Cloud Role Name festlegen, um Dienste in einer Microservices-Architektur zu unterscheiden, und die Stichprobenentnahme (Sampling) sorgfältig konfigurieren, um ein Gleichgewicht zwischen Detailtreue und Kosten zu finden.

Application Insights gibt verschiedene Kern-Telemetrietypen aus:

Anfragen erfassen eingehende Operationen (HTTP-Anfragen, Funktionsaufrufe) mit Dauer, Antwortcode und Erfolg.
Abhängigkeiten erfassen ausgehende Aufrufe (HTTP, SQL, Azure SDK-Aufrufe, Warteschlangen) mit Ziel, Typ, Dauer und Erfolg.
Ausnahmen erfassen ausgelöste Fehler, Stack-Traces und behandelte Ausnahmen, wenn sie explizit verfolgt werden.
Ablaufverfolgungen erfassen Protokollnachrichten; SDKs integrieren sich in gängige Logging-Frameworks, sodass Protokolle und Telemetrie die Korrelation teilen.
Ereignisse erfassen benutzerdefinierte, geschäftsrelevante Vorkommnisse über TrackEvent und unterstützen benutzerdefinierte Dimensionen und Zählungen.
Metriken erfassen numerische Messungen; Sie können benutzerdefinierte Metriken für KPIs verfolgen und diese im Metrics Explorer untersuchen.

Die verteilte Ablaufverfolgung (Distributed Tracing) in Application Insights basiert auf Korrelation. Jede End-to-End-Operation hat eine Operations-ID (Operation ID, in W3C-Begriffen Trace ID), die von zugehörigen Telemetriedaten gemeinsam genutzt wird; jeder Span hat Eltern-Kind-Beziehungen, die durch Propagierungs-Header erzwungen werden. Moderne SDKs verwenden den W3C Trace Context (traceparent, tracestate). Operation_Id in KQL verbindet Anfragen, Abhängigkeiten, Ausnahmen und Ablaufverfolgungen für dieselbe Transaktion. Stellen Sie sicher, dass ausgehende HTTP-Clients die Header weitergeben; bei .NET erledigen dies System.Diagnostics.Activity und das AI SDK automatisch. Die Abhängigkeitsverfolgung instrumentiert gängige Clients (HTTP, SQL, Service Bus, Storage). Wenn Dienste Grenzen überschreiten (z. B. von App Service zu AKS), führt eine konsistente Weitergabe zu einer einzigen, zusammenhängenden Transaktionsübersicht (Transaction Map). Stellen Sie bei asynchronen und nachrichtenbasierten Abläufen sicher, dass die SDKs Korrelations-IDs in den Metadaten der Nachrichten erfassen und weiterleiten; die meisten Azure SDKs tun dies standardmäßig.

Verfügbarkeitstests und synthetische Überwachung

Verfügbarkeitstests validieren die externe Erreichbarkeit und Reaktionsfähigkeit von mehreren geografischen Standorten aus. Der URL-Ping-Test sendet in einer konfigurierten Frequenz HTTP-Anfragen von mehreren Teststandorten aus und validiert Statuscodes, die SSL-Integrität und optional eine Inhaltsübereinstimmung. Verwenden Sie Wiederholungsversuche und mehrere Standorte, um falsch-positive Ergebnisse zu reduzieren, und konfigurieren Sie Warnungen bei Testfehlschlägen für handlungsrelevante Benachrichtigungen.

Mehrstufige Verfügbarkeitstests führten historisch aufgezeichnete Sequenzen von HTTP-Anfragen mit zustandsbehafteten Cookies aus, um Arbeitsabläufe zu überprüfen. Klassische mehrstufige Webtests wurden eingestellt; für Szenarien mit mehreren Anfragen oder Authentifizierung implementieren Sie synthetische Tests, indem Sie Ihren eigenen Client oder Dienst mit der TrackAvailability-API (oder OpenTelemetry-Exportern) instrumentieren, um AvailabilityTelemetry auszugeben. Dieser Ansatz ermöglicht benutzerdefinierte Authentifizierung, Payloads und domänenspezifische Validierung, während das zentrale Reporting und die Alarmierung beibehalten werden.

Benutzerdefiniertes TrackAvailability gibt Ihnen die Kontrolle über:

Testname, Ausführungsort und Sequenzbezeichner für Trendanalysen und Deduplizierung.
Dauer und Erfolgssemantik basierend auf Ihren Validierungen, nicht nur auf dem HTTP-Status.
Aussagekräftige Nachrichten und benutzerdefinierte Dimensionen für Hinweise zur Ursachenanalyse und zur Korrelation mit Backend-Telemetrie.

Kombinieren Sie Verfügbarkeitstests mit Backend-Abhängigkeits- und Anfrage-Telemetrie, um schnell zwischen Problemen mit der Endpunktverfügbarkeit (Netzwerk, DNS, TLS), Anwendungsfehlern (Ausnahmen, Zeitüberschreitungen) und Ausfällen nachgelagerter Systeme (SQL, externe APIs) zu unterscheiden. Verknüpfen Sie Fehler bei Verfügbarkeitstests mit Aktionsgruppen, um Incident-Workflows anzustoßen.

Azure Monitor-Daten, KQL und Warnungen mit Aktionsgruppen

Azure Monitor erfasst zwei primäre Datentypen: Metriken und Protokolle. Metriken sind schlanke, numerische Zeitreihen mit Erfassung in Quasi-Echtzeit und mehrdimensionaler Aufschlüsselung (z. B. nach Instanz, API-Route). Sie eignen sich am besten für die schnelle Erkennung (CPU, Arbeitsspeicher, Anforderungsrate, Latenz, Verfügbarkeit) und unterstützen standardmäßig eine Aufbewahrung von bis zu 93 Tagen. Protokolle sind strukturierte, abfragbare Datensätze, die in einem Log Analytics-Arbeitsbereich gespeichert werden und Daten von Application Insights, Plattformressourcenprotokolle sowie benutzerdefinierte Protokolle mit konfigurierbarer Aufbewahrungsdauer umfassen. Verwenden Sie Diagnoseeinstellungen, um Plattformmetriken und Ressourcenprotokolle zur Archivierung und Analyse an einen Arbeitsbereich, einen Event Hub oder einen Storage-Account weiterzuleiten.

Die Kusto Query Language (KQL) ist die Grundlage für explorative Analysen, Dashboards und Protokollwarnungen. Zu den Kernmustern gehören:

Grundlegende Abfragen: Tabelle | take 10 für schnelle Stichproben; schränken Sie den Zeitraum für eine bessere Leistung immer frühzeitig mit where TimeGenerated >= ago(…) ein.
Filtern und Projizieren: Tabelle | where Spalte == “Wert” | project Schlüsselfelder, um die Datenmenge (Payload) zu reduzieren und die Analyse zu fokussieren.
Aggregation: summarize count() by bin(TimeGenerated, 5m), Dimension, um Raten, Perzentile oder Durchschnittswerte zu berechnen; verwenden Sie percentile() und make-series für Zeitdiagramme.
Joins: join kind=inner oder leftouter über Korrelationsschlüssel wie operation_Id, um Requests mit Dependencies oder Exceptions zu verbinden; stellen Sie bei ressourcenübergreifenden Joins sicher, dass beide an denselben Arbeitsbereich senden, oder aktivieren Sie ressourcenübergreifende Abfragen.
Nützliche Tabellen: requests, dependencies, exceptions, traces, availabilityResults für Application Insights; AzureDiagnostics und AzureActivity für Plattformprotokolle; Perf und Heartbeat für VM Insights.
Best Practices: Projizieren Sie nur benötigte Spalten, filtern Sie frühzeitig, bündeln Sie (bin) in sinnvollen Intervallen und vermeiden Sie teure Cross-Joins über große Zeitfenster, sofern nicht erforderlich.

Warnungen (Alerting) umfassen Metriken und Protokolle. Metrikwarnungen werten Metrikschwellenwerte in Quasi-Echtzeit aus, unterstützen Dimensionen sowie die Aufteilung nach Dimensionen und können statische oder dynamische Schwellenwerte (ML-basierte Baselines) verwenden. Sie sind zustandsbehaftet (stateful) und können basierend auf den Auswertungsergebnissen auslösen und sich automatisch auflösen, wobei bei einer Zustandsänderung eine Benachrichtigung erzeugt wird. Protokollwarnungen (geplante Abfragen) führen KQL in einem bestimmten Rhythmus aus und werden durch Abfrageergebnisse ausgelöst (Anzahl der Übereinstimmungen oder Schwellenwerte für Messwerte). Verwenden Sie Protokollwarnungen, wenn Bedingungen von komplexen Mustern über mehrere Tabellen hinweg abhängen oder eine Textanalyse erfordern. Intelligente Erkennung (Smart Detection) und Anomaliewarnungen in Application Insights können Regressionen ohne explizite Schwellenwerte hervorheben.

Aktionsgruppen (Action Groups) definieren wiederverwendbare Reaktionssätze für Warnungen. Zu den Benachrichtigungstypen gehören E-Mail, SMS, Sprachanruf und Push-Benachrichtigungen an die mobile Azure-App. Integrationen umfassen:

Webhooks (v1 und v2) mit dem Common Alert Schema für konsistente Payloads; legen Sie benutzerdefinierte Header für die Authentifizierung fest und leiten Sie sie an Incident-Systeme (z. B. PagerDuty oder benutzerdefinierte Empfänger) weiter.
Azure Functions, Logic Apps und Automation-Runbooks für die programmgesteuerte Behebung und Anreicherung; verwenden Sie Logic Apps für flexible Transformationen und Konnektoren.
ITSM-Konnektoren (z. B. ServiceNow), um Incidents mit zugeordneten Feldern zu öffnen. Kombinieren Sie Aktionsgruppen mit Warnungsverarbeitungsregeln (Alert Processing Rules), um Warnungen während Wartungsarbeiten zu unterdrücken, sie nach Schweregrad weiterzuleiten oder dynamische Aktionen anzuwenden. Für sichere ausgehende Webhooks beschränken Sie den Empfänger auf Azure-IPs oder verlangen Sie Signaturen/Header und validieren Sie die Eigenschaften des Common Alert Schema wie Essentials.AlertRule und AlertContext.

ARM-Vorlagen für Überwachbarkeit und wiederholbare Bereitstellung

Azure Resource Manager (ARM)-Vorlagen definieren Ressourcen und Überwachungskonfigurationen deklarativ als Code. Die Struktur einer Vorlage umfasst:

$schema und contentVersion, um die Vorlagenversion zu identifizieren.
Parameter für externalisierte Werte (z. B. Arbeitsbereichsnamen, Standorte, SKUs). Verwenden Sie secureString/secureObject für Geheimnisse.
Variablen für berechnete Werte, um Wiederholungen zu vermeiden.
Ressourcen für die deklarative Bereitstellung von Application Insights, Log Analytics-Arbeitsbereichen, Warnungsregeln, Aktionsgruppen und Diagnoseeinstellungen.
Ausgaben, um Werte wie den Application Insights connectionString für nachgelagerte Bereitstellungsphasen auszugeben.

Verwenden Sie verknüpfte oder verschachtelte Vorlagen, um komplexe Bereitstellungen zusammenzustellen. Eine Bereitstellungsressource (Microsoft.Resources/deployments) referenziert eine untergeordnete Vorlage über templateLink (externe URI) oder bettet sie inline ein. Übergeben Sie Parameterobjekte über parameters oder parametersLink, definieren Sie dependsOn für die Reihenfolge und verwenden Sie Module umgebungsübergreifend wieder. Beispiele für standardmäßig integrierte Überwachbarkeit durch ARM:

Einen Log Analytics-Arbeitsbereich bereitstellen und workspaceResourceId-Ausgaben festlegen, die von Application Insights-Ressourcen verwendet werden (arbeitsbereichsbasierter Modus).
Application Insights (arbeitsbereichsbasiert) erstellen und dessen connectionString ausgeben; vermeiden Sie die Offenlegung veralteter Instrumentation Keys.
Diagnoseeinstellungen für Ressourcen (z. B. App Service, Key Vault, Storage) aktivieren, um Protokolle und Metriken an den Arbeitsbereich und/oder Event Hub zu streamen.
Metrikwarnungen (microsoft.insights/metricAlerts) mit Kriterien und Dimensionen sowie geplante Abfragewarnungen (microsoft.insights/scheduledQueryRules) mit KQL bereitstellen und Aktionsgruppen über die Ressourcen-ID verknüpfen.
Aktionsgruppen (microsoft.insights/actionGroups) mit E-Mail/SMS- und Webhook-Empfängern definieren; Adressen und Endpunkte für umgebungsspezifisches Routing parametrisieren.

Nutzen Sie Bedingungen und Kopierschleifen für skalierbare Bereitstellungen (z. B. das Anwenden von Diagnoseeinstellungen auf eine Reihe von Ressourcen-IDs). Verwenden Sie ARM-Funktionen wie resourceId, subscriptionResourceId, reference, concat und guid, um dynamische Referenzen und stabile Namen zu erstellen. Halten Sie die Telemetriekonfiguration dienstübergreifend konsistent, indem Sie Konventionen für Rollennamen und das Sampling in App-Einstellungen zentralisieren, die über ARM- oder App Service-Konfigurationsressourcen bereitgestellt werden.

Praktisches Problemszenario

Adobe benötigt End-to-End-Observability für eine neue, multiregionale Medienverarbeitungspipeline, die auf Azure App Service APIs und AKS-Microservices aufbaut. Sie benötigen eine schnelle Erkennung von Latenzregressionen, eine verteilte Ablaufverfolgung über Dienste hinweg, proaktive Verfügbarkeitsprüfungen für öffentliche Endpunkte und ein automatisiertes Incident-Routing zu ihrem System für die Rufbereitschaft mit der Wiederholbarkeit von Infrastructure-as-Code.

Dienste mit Application Insights unter Verwendung von Verbindungszeichenfolgen instrumentieren

Konfigurieren Sie jeden App Service- und AKS-Workload so, dass er die Application Insights-Verbindungszeichenfolge anstelle von veralteten Schlüsseln verwendet, um korrekte Ingestion-Endpunkte und zukunftssicheres Routing zu gewährleisten. Legen Sie Cloud-Rollennamen pro Dienst fest, um eine klare Filterung und Darstellung in Karten zu ermöglichen. Wählen Sie eine SDK-basierte Instrumentierung in den Kern-APIs, um Domänenereignisse und Metriken auszugeben; aktivieren Sie Codeless Attach für Hilfsdienste, um die Abdeckung zu beschleunigen. Warum: Verbindungszeichenfolgen ermöglichen Flexibilität bei den Endpunkten; SDKs bieten benutzerdefinierte Telemetrie, während Codeless Attach die Einführungskosten niedrig hält.

Verteilte Ablaufverfolgung und Abhängigkeitsverfolgung aktivieren

Stellen Sie sicher, dass ausgehende HTTP-Clients und Azure SDKs den W3C-Trace-Kontext weitergeben; überprüfen Sie die Kontinuität der operation_Id in KQL. Bestätigen Sie bei Hintergrund-Nachrichtenflüssen (Service Bus), dass die Korrelation von den SDKs injiziert und extrahiert wird; ergänzen Sie dies durch TelemetryInitializers, wo benutzerdefinierte Header verwendet werden. Warum: Eine konsistente Weitergabe der Ablaufverfolgung führt zu einer genauen End-to-End-Latenz- und Fehlerzuordnung über Microservices hinweg.

Verfügbarkeitstests und benutzerdefinierte synthetische Prüfungen implementieren

Konfigurieren Sie URL-Ping-Tests für öffentliche APIs aus mehreren Regionen mit Inhaltsabgleich auf einem schlanken Health-Endpunkt. Implementieren Sie für authentifizierte Abläufe (Token-Erwerb und Medienübermittlung) einen synthetischen Client, der den Workflow aufruft und TrackAvailability-Ergebnisse mit Ausführungsort und detaillierten Nachrichten ausgibt. Warum: URL-Pings bieten eine schnelle externe Überprüfung; TrackAvailability unterstützt komplexe, authentifizierte Geschäftsabläufe, die über einfache Pings hinausgehen.

Daten in einem Log Analytics-Arbeitsbereich zentralisieren und Plattformprotokolle weiterleiten

Stellen Sie einen Arbeitsbereich bereit und konfigurieren Sie Diagnoseeinstellungen für App Services, AKS-Steuerungsebenenprotokolle, Key Vault und Storage, um Protokolle und Metriken in den Arbeitsbereich zu streamen. Stellen Sie sicher, dass Application Insights-Ressourcen arbeitsbereichsbasiert sind, um Abfragen zu vereinheitlichen. Warum: Ein einziger Arbeitsbereich ermöglicht dienstübergreifende KQL-Abfragen, die Anfragen, Abhängigkeiten und Plattformprotokolle für eine ganzheitliche Untersuchung zusammenführen.

Metrik- und Protokollwarnungen mit Aktionsgruppen erstellen

Definieren Sie Metrikwarnungen für Perzentile der Anforderungsdauer und Verfügbarkeit nach Standort mit dynamischen Schwellenwerten, aufgeteilt nach Cloud-Rollennamen. Fügen Sie geplante Abfragewarnungen hinzu, die Fehlerspitzen nach Operationsnamen erkennen und mit Abhängigkeitsfehlern korrelieren, indem Sie einen KQL-Join auf der operation_Id verwenden. Warum: Metrikwarnungen ermöglichen eine Erkennung nahezu in Echtzeit; Protokollwarnungen erfassen komplexe Muster, die nicht als einfache Schwellenwerte ausgedrückt werden können.

Incident Response über Aktionsgruppen und Webhooks integrieren

Konfigurieren Sie eine Aktionsgruppe mit E-Mail für Service-Owner, SMS für On-Call-Leads und einem sicheren Webhook zur Incident-Plattform von Adobe unter Verwendung des Common Alert Schema. Fügen Sie einen Logic App-Empfänger hinzu, um Payloads mit aktuellen KQL-Abfrageergebnissen und Topologie-Metadaten anzureichern. Warum: Mehrkanalige Benachrichtigungen reduzieren die MTTA; Webhook und Logic App ermöglichen automatisiertes Ticketing und kontextreiche Incidents.

Überwachung mit ARM-Vorlagen kodifizieren

Erstellen Sie ARM-Vorlagen, um den Log Analytics-Arbeitsbereich, Application Insights (arbeitsbereichsbasiert), Diagnoseeinstellungen, Metrikwarnungen, geplante Abfragewarnungen und Aktionsgruppen bereitzustellen. Parametrisieren Sie Umgebungsnamen, Regionen und Kontaktpunkte; geben Sie den Application Insights connectionString für die nachgelagerte App-Konfiguration aus. Verwenden Sie verknüpfte Vorlagen für teameigene Module (Plattform vs. App). Warum: Infrastructure-as-Code gewährleistet eine konsistente, wiederholbare Observability über Entwicklungs-, Staging- und Produktionsumgebungen hinweg und unterstützt CI/CD.

Mit KQL-Dashboards validieren

Erstellen Sie Dashboards mit KQL, die die Latenz nach Dienst zusammenfassen (Perzentile nach Intervall und Rolle zusammenfassen), Fehlerraten mit Abhängigkeitszielen verknüpfen und die synthetische Verfügbarkeit nach Standort darstellen. Integrieren Sie Zeitbereichsfilter und Drill-Through-Funktionen zu Traces und Ausnahmen. Warum: KQL bietet flexible Analysen und handlungsorientierte Visualisierungen für Engineering und Betrieb.

← Azure Caching · Alle Domänen

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →