Wissen ist Macht – Azure Monitor einsetzen
Teil 2 – Metriken
Auch Azure stellt wie alle Public-Cloud-Anbieter mit dem Azure Monitor einen zentralen Überwachungsdienst zu Verfügung. Mit ihm kannst du Performance und Verfügbarkeit oder Kosten und Nutzung deiner Anwendungen und Dienste kontrollieren, sowie Security-Audits durchführen. Microsoft positioniert den Dienst als All-in-One-Solution für das Sammeln, Analysieren und Behandeln von Telemetriedaten aus der Azure-Cloud, anderen Clouds und lokalen Umgebungen. In drei Teilen stellen wir dir die wichtigsten Funktionen und Anwendungsbereiche vor. Dieses ist der zweite Teil.
Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!
Azure Monitor Metrics
Azure Monitor Metrics (Metrics Explorer) widmet sich klassischen Metriken. Du kannst das Modul im Azure Monitor auswählen und dann den gewünschten „Bereich“ (z. B. Virtuelle Maschine) bestimmen wie in der Abbildung 1 zu sehen, oder du navigierst im Azure Portal „vorher“ zur gewünschten Ressource (z. B. virtuelle Maschine) und wählst dort im Navigationsmenü auf der linken Seite im Abschnitt „Überwachung“ den Eintrag „Metriken“. Hier ist bei „Bereich“ die gewählte virtuelle Maschine bereits eingetragen. Als „Metriknamespace“ ist per Default nur „Host der virtuellen Maschine“ verfügbar, d. h. hier werden standardmäßig Metriken auf Hostebene – wie z. B. CPU-Auslastung, Datenträger- und Netzwerknutzung erfasst -, ohne dass hierzu zusätzliche Agenten erforderlich sind. Erst wenn du später die Diagnoseerweiterung für VMs aktivierst, kannst du weitere Erkenntnisse über die gewählte VM auf Gast-Ebene, sowie zusätzliche Protokolle und weitere Diagnosedaten erfassen.
Bild 2 zeigt aus dem Namespace „Host-Metriken“ die aggregierte prozentuale CPU-Auslastung.
Du erhältst so ein selbst erstelltes Diagramm. Allerdings gehört die CPU-Auslastung ohnehin zu den Standard-Diagrammen für virtuelle Maschinen. Du findest dieses und eine Reihe weitere Standard-Diagramme auf Basis von Host-Metriken, wenn du auf der „Übersicht“-Seite im Azure-Portal für virtuelle Maschinen auf den Tab „Überwachung“ klickst.
Hier kannst du z. B. in eines der Diagramme hinein klicken und das Diagramm um eine weitere Metrik ergänzen. Du kannst aber auch im Azure Monitor selbst (dann musst du erst wieder den gewünschten „Scope“ wählen) oder im VM-Menü unter „Überwachung / Metriken“ neue Diagramme erstellen. Im letzteren Fall ist der Scope mit der gewählten VM bereits „gesetzt“ und du musst nur noch den „Metriknamespace“ (per Default geht nur „Host der virtuellen Maschine“) und die gewünschte „Metrik“ sowie die gewünschte „Aggregation“ auswählen. Du kannst auch mehrere Metriken in ein Diagramm packen.
Standard-Metriken vom Hypervisor sind wichtig aber nichts Besonderes. Um mehr Einblicke in deine VM oder Anwendung zu erhalten kannst du entweder den Gastsystem-Diagnose-Agent und/oder den Log-Analytics-Agenten auf der VM aktivieren. Beide überschneiden sich wie eingangs erwähnt darin, welche Daten du erfasst, wohin du die Daten speicherst oder streamst und mit welchen Tools die Daten abgefragt werden können (Azure Monitor Metrics oder Azure Monitor Logs).
Den Diagnose-Agenten kannst du entweder beim Neuerstellen einer VM mit Tab „Verwaltung“ mit Setzen des Häkchens bei „Diagnose des Gastbetriebssystems“ aktivieren“ oder bei bereits erstellter VM im Menü „Überwachung / Diagnoseeinstellungen“ mit einem Klick auf den Button „Überwachung auf Gastebene aktivieren“ installieren. In beiden Fällen musst du zu diesem Zweck ein Speicherkonto angeben oder erstellen (lassen), in dem die erfassten Diagnosedaten zusätzlich zur Integration mit Azure Monitor Metrics gespeichert werden. Die Gastsystem-Diagnose-Metriken werden übrigens alle 60 Sekunden erfasst. In Zukunft sieht Microsoft offenbar den Azure-Monitor-Agent an prominentester Stelle. Der erfasst derzeit aber nur Ereignisprotokolle und Performance-Daten, sendet diese sowohl an Azure Monitor Logs als auch Azure Monitor Metrics, sodass diese mit dem Metrik Explorer UND Log Analytics ausgewertet werden können. Derzeit sind aber der Log Analytics Agent und die Diagnoseerweiterung deutlich mächtiger, wobei letztere die Daten zusätzlich in einem Speicherkonto ablegt und an Event Hub streamen kann.
Wurde der Agent einmalig aktiviert, zeigt der gleiche Menüeintrag z. B. im Anschnitt Übersicht zu welchen Leistungsindikatoren Daten gesammelt werden (CPU, Arbeitsspeicher, Datenträger, Netzwerk) und welche Ereignisprotokolle erfasst werden. Hier sind das „Anwendung“ (Kritisch, Fehler, Warnung), „Sicherheit“ (Überwachungsfehler) und „System“ (Kritisch, Fehler, Warnung). Genauer kannst du das in den entsprechenden Tabs „Leistungsindikatoren““, „Protokolle“ oder „Absturzabbilder sehen.
Ist der Diagnose-Agent aktiviert, hast du in Azure Monitor Metrics bei der Diagrammerstellung bei „Metriknamespace“ nun die Möglichkeit zusätzlich zu „Host der virtuellen Maschine“ auch „Gast (klassisch) oder „Neue Metriken für Gastarbeitsspeicher“ auszuwählen, wobei letzteres derzeit noch Preview-Status hat.
Du kannst dann künftig Metriken direkt in den Azure Monitor-Metrikspeicher schreiben, in dem bereits Standard-Plattform-Metriken erfasst werden und damit auf dieselben Aktionen zugreifen, die für Diese verfügbar sind, wie z. B. Alarmierung in Quasi-Echtzeit, Diagrammerstellung, Routing, Zugriff über die REST-API und mehr. Natürlich sind solche Metriken dann nicht mehr kostenlos, wie z. B. die Plattform-Metriken. Wählst du „Gast (klassisch)“ als Metriknamespace musst du zuvor den Ressourcenanbieter „Microsoft. Insights“ registrieren. Dies kannst du wahlweise im Azure-Portal auf Abonnement-Ebene im Menü „Ressourcenanbieter“ tun oder einfacher in der CloudShell via PowerShell:
Register-AzResourceProvider -ProviderNamespace Microsoft.Insights
Nun kannst du problemlos Diagramme für Gast-Metriken konfigurieren. Die Auswahl an Metriken ist hier deutlich größer.
Welcher Agent für was?
Einblicke ins Gastsystem erhältst du aber nicht nur über den Diagnose-Agenten, sondern wahlweise auch über den Log-Analytics-Agenten. Doch während die Diagnose-Erweiterung in Summer mehr Daten sammelt (Ereignisprotokolle, ETW-Ereignisse, Leistung, Dateibasierte Protokolle, IIS-Protokolle, .NET-App-Protokolle, Absturzabbilder, Agent-Diagnoseprotokolle), als der Log-Analytics-Agent (Ereignisprotokolle, Leistung, Dateibasierte Protokolle, IIS-Protokolle, Insights), steht der Diagnose-Agent nur für Azure VMs zur Verfügung, während du den Log-Analytics-Agenten auch auf lokalen VMs, lokalen Computern oder VMs in AWS oder Google installieren kannst.
Bevor du dich also mit Azure Log Analytics befasst, solltest du dir eine Übersicht der verfügbaren Monitoring-Agents für Windows und Linux verschaffen. Wegen der eingangs skizzierten seit 2019 laufenden Konsolidierung von Azure Monitor und Log Analytics verfügt Azure Monitor über mehrere Agenten. Genau genommen über vier verschiedene Windows-Agents (Azure-Monitor-Agent, Diagnoseerweiterung (WAD), Log-Analytics-Agent, Dependency-Agent) und fünf verschiedene Linux-Agents (Azure-Monitor-Agent, Diagnoseerweiterung (LAD), Log-Analytics-Agent, Telegraf-Agent, Dependency-Agent). Alle unterschieden sich hinsichtlich der unterstützten Umgebungen (Azure, lokal, Multi-Cloud/Azure-Arc), der gesammelten Daten (s. o), der Speicher-/Analyse-Plattform an welche die Daten gesendet werden (Azure Monitor Metrics, Azure Monitor Logs, Speicherkonto oder Event Hub) und der Tools, mit welchen die Daten abgefragt werden können (Azure Monitor Metrics Explorer, Azure Monitor Log-Analytics, Azure Automation, Azure Security Center, Azure Sentinel). Die Linux-Agents unterscheiden sich von den Windows-Agents vor allem hinsichtlich der gesammelten Daten. Hier geht es fast ausnahmslos entweder um Leistungs-Daten oder Syslog. Da sich die verschiedenen Agenten hinsichtlich der geschilderten Eigenschaften zum Teil überschneiden, kann es schwierig sein, hier die richtige Wahl zu treffen, auch hinsichtlich der entstehenden Kosten. Microsoft schreibt dazu auf seiner Übersichtsseite zu den https://docs.microsoft.com/de-de/azure/azure-monitor/agents/agents-overview verfügbaren Agents selbst: „Es kann vorkommen, dass spezifische Anforderungen für einen bestimmten Computer nicht vollständig durch einen einzelnen Agenten erfüllt werden können.“
Kontakt
„*“ zeigt erforderliche Felder an