In der heutigen Cloud-Welt ist eine präzise Überwachung (Monitoring) unerlässlich, um die Gesundheit, Leistung und Verfügbarkeit Ihrer Anwendungen und Infrastruktur sicherzustellen. Azure Monitor ist dabei das zentrale Nervensystem für das Beobachten Ihrer Ressourcen in Microsoft Azure. Ein entscheidender Baustein dieser Überwachung ist der Azure Monitoring Agent, der fleißig Daten von Ihren virtuellen Maschinen sammelt und an Azure Monitor sendet. Doch was tun, wenn dieser Agent plötzlich schweigt und keine Performance-Metriken mehr liefert? Die Auswirkungen können gravierend sein: Blinde Flecken in Ihrer Infrastruktur, verpasste Engpässe und erschwerte Fehlerdiagnose. Dieser umfassende Troubleshooting-Guide führt Sie Schritt für Schritt durch die Diagnose und Behebung der häufigsten Ursachen für fehlende Performance-Metriken.
Ziel dieses Artikels ist es, Ihnen eine detaillierte Anleitung zur Verfügung zu stellen, damit Sie schnell und effizient die Ursache des Problems identifizieren und beheben können. Egal ob Sie ein erfahrener Cloud-Administrator oder ein DevOps-Ingenieur sind, der sich mit Azure beschäftigt, dieser Guide wird Ihnen wertvolle Einblicke und praktische Lösungen bieten.
Grundlagen verstehen: Der Azure Monitoring Agent und seine Rolle
Bevor wir uns ins Troubleshooting stürzen, ist es wichtig, die Funktionsweise des Azure Monitoring Agents (AMA) zu verstehen. Der AMA ist ein leichter Agent, der auf virtuellen Maschinen (VMs) – sowohl in Azure als auch außerhalb (Azure Arc-fähige Server) – installiert wird. Seine Hauptaufgabe ist es, Daten von diesen Maschinen zu sammeln und an verschiedene Azure Monitor-Dienste zu senden, primär an Log Analytics Workspaces oder Azure Monitor Metriken. Er ist der Nachfolger des älteren Log Analytics Agents (MMA/OMS Agent) und bietet eine flexiblere und effizientere Datensammlung durch Data Collection Rules (DCRs).
Performance-Metriken, wie CPU-Auslastung, Speichernutzung, Disk-I/O oder Netzwerkdurchsatz, sind entscheidend für die Leistungsanalyse, Kapazitätsplanung und proaktive Problemidentifizierung. Wenn diese Daten fehlen, arbeiten Sie im Blindflug.
Die Schlüsselkomponenten, die für die Sammlung und Übermittlung von Performance-Metriken durch den AMA zusammenarbeiten, sind:
- Der Azure Monitoring Agent selbst, installiert auf der VM.
- Die Data Collection Rules (DCRs), die definieren, welche Daten gesammelt und wohin sie gesendet werden sollen.
- Der Log Analytics Workspace oder der Azure Monitor Metriken-Speicher als Ziel für die gesammelten Daten.
- Die Netzwerkverbindung von der VM zu den Azure-Endpoints.
Erste Schritte der Fehlerbehebung: Die Basics prüfen
Oftmals sind die einfachsten Ursachen die schwierigsten zu finden. Beginnen Sie Ihr Troubleshooting stets mit den grundlegendsten Prüfungen:
1. Agent-Status überprüfen
Ist der Azure Monitoring Agent überhaupt aktiv? Ein nicht laufender Dienst kann naturgemäß keine Daten senden.
- Für Windows-VMs: Öffnen Sie die Diensteverwaltung (services.msc) und suchen Sie nach dem Dienst namens „Azure Monitor Agent”. Stellen Sie sicher, dass der Dienststatus „Wird ausgeführt” ist und der Starttyp auf „Automatisch” gesetzt ist. Bei Problemen versuchen Sie, den Dienst neu zu starten.
- Für Linux-VMs: Verwenden Sie den Befehl
systemctl status azuremonitoragent
. Überprüfen Sie, ob der Dienst aktiv ist. Falls nicht, starten Sie ihn mitsudo systemctl start azuremonitoragent
oder aktivieren Sie ihn mitsudo systemctl enable azuremonitoragent
.
2. Konnektivität überprüfen
Der Agent benötigt eine funktionierende Netzwerkverbindung zu den Azure Monitor-Endpoints, um Daten hochladen zu können. Häufige Probleme hierbei sind Firewall-Regeln, Proxy-Einstellungen oder DNS-Probleme.
- Firewall: Überprüfen Sie, ob die lokale Firewall der VM (Windows Defender Firewall, iptables/firewalld unter Linux) oder eine Netzwerk-Firewall (NSG, Azure Firewall, On-Premises Firewall) den ausgehenden Verkehr blockiert. Der Agent benötigt Zugriff auf die Azure Monitor-Service-Tags für die entsprechenden Regionen. Typische Ports sind TCP 443 (HTTPS).
- Proxy-Einstellungen: Wenn Ihre Umgebung einen Proxy verwendet, muss der Agent korrekt konfiguriert sein, um diesen zu nutzen. Die Proxy-Einstellungen werden in der Regel über Umgebungsvariablen oder Agent-Konfigurationsdateien definiert. Überprüfen Sie die offizielle Azure-Dokumentation für die spezifische Konfiguration.
- DNS-Auflösung: Stellen Sie sicher, dass die VM die Azure-Endpunkte korrekt auflösen kann (z.B.
.ods.opinsights.azure.com
oderglobal.handler.control.monitor.azure.com
). Ein einfachernslookup
-Befehl kann hier Klarheit schaffen.
3. Agent-Version und Kompatibilität
Veraltete Agent-Versionen können Kompatibilitätsprobleme mit neueren Azure-Features oder dem Betriebssystem haben. Stellen Sie sicher, dass der Agent auf dem neuesten Stand ist. Überprüfen Sie auch, ob das Betriebssystem der VM eine von Azure Monitor unterstützte Version ist.
4. Log Analytics Workspace überprüfen
Stellen Sie sicher, dass der Ziel-Log Analytics Workspace, an den die Daten gesendet werden sollen, existiert und korrekt konfiguriert ist. Überprüfen Sie im Azure-Portal, ob der Workspace erreichbar ist und keine Sperren oder Berechtigungsprobleme aufweist.
Tiefere Diagnose: Data Collection Rules (DCRs) im Fokus
Der Azure Monitoring Agent arbeitet nicht autonom, sondern wird durch Data Collection Rules (DCRs) gesteuert. Diese Regeln sind das Herzstück der flexiblen Datensammlung und oft die Quelle von Problemen bei fehlenden Metriken.
1. Was sind DCRs?
Eine DCR definiert:
- Datenquellen: Welche Art von Daten gesammelt werden soll (z.B. Performance Counter, Ereignisprotokolle, Syslog).
- Datenströme: Wie die gesammelten Daten verarbeitet und transformiert werden sollen (Optional, z.B. KQL-Transformationen).
- Ziele: Wohin die Daten gesendet werden sollen (z.B. Log Analytics Workspace, Azure Monitor Metriken, Azure Event Hubs).
Für Performance-Metriken ist es entscheidend, dass die DCR korrekt konfiguriert ist, um die gewünschten Zähler zu erfassen und an den richtigen Zielort zu senden.
2. DCR-Konfiguration prüfen
Navigieren Sie im Azure-Portal zu Ihrer VM und dort zum Bereich „Insights” oder „Extensions + applications”, um die zugewiesenen DCRs zu überprüfen. Alternativ suchen Sie direkt nach „Data Collection Rules”.
- Zuweisung zur VM: Ist die DCR der betroffenen VM oder dem VM-Skalierungssatz tatsächlich zugewiesen? Eine fehlende Zuweisung ist ein häufiger Fehler.
- Performance-Counter-Definition: Öffnen Sie die DCR und überprüfen Sie unter „Data sources” -> „Performance counters”. Sind die benötigten Performance-Counter (z.B. „Processor(*)% Processor Time”, „Memory% Committed Bytes In Use”) korrekt definiert?
- Stellen Sie sicher, dass der Objektname, der Zählername und die Instanz (z.B. `_Total` oder `*` für alle Instanzen) exakt den Namen auf der VM entsprechen. Tippfehler sind hier fatal.
- Überprüfen Sie das Abtastintervall. Ist es zu lang (z.B. 1 Stunde), erscheinen die Metriken nur selten oder mit großer Verzögerung. Ein gängiges Intervall ist 60 Sekunden.
- Ziel für Performance-Metriken: Stellen Sie sicher, dass die Performance-Metriken an den korrekten Log Analytics Workspace oder als Azure Monitor Metriken gesendet werden. Dies ist im „Destinations”-Bereich der DCR konfiguriert.
- Berechtigungen der DCR: Die DCR selbst benötigt keine direkten Berechtigungen auf dem Workspace, aber die zugrunde liegende Identität (Managed Identity der VM oder Benutzerkontext, unter dem der Agent läuft) benötigt die Rolle „Log Analytics Contributor” für den Ziel-Workspace.
3. Validierung der DCR
Manchmal hilft es, eine einfache, vordefinierte DCR zu verwenden oder eine neue, minimale DCR nur für einen einzigen Performance-Counter zu erstellen und der VM zuzuweisen. Wenn diese einfache DCR funktioniert, deutet dies auf ein Problem in Ihrer komplexeren DCR hin. Nutzen Sie die Überprüfungsfunktionen im Azure-Portal, um die Syntax Ihrer DCR zu validieren.
Agent-Logs analysieren: Die Geheimnisse lüften
Die Agent-Logs sind Ihr bester Freund bei der Fehlersuche. Sie enthalten detaillierte Informationen über den Betrieb des Agents, Konnektivitätsprobleme, DCR-Verarbeitung und potenzielle Fehler beim Senden von Daten.
1. Wo finde ich die Logs?
- Für Windows-VMs: Die Logs befinden sich typischerweise unter
C:ProgramDataAzureMonitorAgentLogs
. Die wichtigsten Dateien sindAMA.Extensions.log
undAMA.Service.log
. - Für Linux-VMs: Die Logs finden Sie unter
/var/opt/microsoft/azuremonitoragent/log
. Hier sind ebenfalls `ama-logs` und `ama-service` relevante Logdateien.
2. Was suche ich in den Logs?
Durchsuchen Sie die Logs nach Schlüsselwörtern, die auf Probleme hinweisen:
- Fehlermeldungen: Suchen Sie nach „Error”, „Failed”, „Exception”, „Critical”. Diese weisen auf schwerwiegende Probleme hin.
- Warnungen: „Warning” kann auf Konfigurationsprobleme oder temporäre Ausfälle hindeuten.
- Konnektivität: Suchen Sie nach Meldungen bezüglich „Connection”, „Network”, „Proxy”, „Endpoint”, „Upload”. Dies hilft, Netzwerkprobleme zu identifizieren.
- DCR-Verarbeitung: Meldungen, die „DCR”, „Data Collection Rule”, „Configuration” enthalten, können auf Probleme beim Parsen oder Anwenden der DCR hinweisen.
- Performance-Counter-Sammlung: Suchen Sie nach Einträgen, die die Sammlung von Performance-Countern bestätigen oder Fehler bei deren Abruf melden.
- Upload-Status: Meldungen wie „Successfully uploaded” oder „Failed to upload” geben Auskunft über den Erfolg der Datenübermittlung.
Achten Sie auf Zeitstempel in den Logs, um den Kontext der Fehlermeldungen zu verstehen.
Spezifische Probleme und Lösungen
1. Fehlende Berechtigungen
Der Azure Monitoring Agent benötigt Berechtigungen, um Performance-Daten vom Betriebssystem zu lesen und diese an den Log Analytics Workspace zu senden. Häufig wird eine Managed Identity für die VM verwendet, die über die Rolle „Monitoring Metrics Publisher” für das Abonnement oder „Log Analytics Contributor” für den Workspace verfügen muss, um Daten senden zu können.
- Lösung: Überprüfen Sie im Azure-Portal unter der VM-Ressource den Bereich „Identity” (Verwaltete Identitäten). Stellen Sie sicher, dass eine System- oder Benutzer-zugewiesene Managed Identity aktiviert ist und die notwendigen Rollenzuweisungen für den Ziel-Workspace besitzt.
2. Zeitliche Verzögerung (Latenz)
Manchmal werden Metriken gesendet, kommen aber mit erheblicher Verzögerung an. Dies kann verschiedene Ursachen haben:
- Netzwerkbandbreite: Eine überlastete Netzwerkverbindung von der VM zu Azure kann den Upload verzögern.
- Agent-Auslastung: Wenn der Agent zu viele Daten sammeln muss oder auf einer ressourcenschwachen VM läuft, kann er überlastet sein.
- Ingestion-Latenz im Log Analytics Workspace: Es kann eine geringe Verzögerung bei der Datenaufnahme in Log Analytics geben, die aber in der Regel nur wenige Minuten beträgt.
- Lösung: Reduzieren Sie die Anzahl der gesammelten Performance-Counter oder erhöhen Sie das Abtastintervall in der DCR. Überprüfen Sie die VM-Ressourcenauslastung und die Netzwerklatenz.
3. Konflikte mit anderen Monitoring-Tools
Obwohl selten, können andere installierte Monitoring-Agenten oder Software auf der VM Ressourcen blockieren oder Konflikte verursachen, die die Sammlung von Performance-Countern beeinträchtigen. Dies ist besonders relevant, wenn multiple Agenten versuchen, auf dieselben Performance-Counter-Bibliotheken zuzugreifen.
- Lösung: Testen Sie, ob das Problem auch auftritt, wenn andere Monitoring-Agenten deaktiviert sind.
4. Windows Performance Counters defekt
Unter Windows können die Performance Counter Bibliotheken (DLLs) korrupt werden, was dazu führt, dass keine Performance-Daten mehr gelesen werden können.
- Lösung: Als Administrator in der Eingabeaufforderung
lodctr /r
ausführen, um die Performance Counter Bibliotheken neu aufzubauen. Anschließend den Azure Monitoring Agent-Dienst neu starten.
5. Linux `perf` oder Dateisystem-Probleme
Auf Linux-Systemen können spezifische Performance-Metriken von Kernel-Modulen oder Tools wie `perf` abhängen. Probleme mit diesen Komponenten oder auch unzureichender Speicherplatz können die Datensammlung behindern.
- Lösung: Überprüfen Sie den Festplattenspeicher der VM. Stellen Sie sicher, dass grundlegende Systemdiagnosetools funktionieren.
Best Practices und Proaktive Maßnahmen
Um zukünftige Probleme zu vermeiden, etablieren Sie folgende Best Practices:
- Regelmäßige Überprüfung der Agent-Gesundheit: Erstellen Sie Azure Monitor Alerts, die Sie benachrichtigen, wenn ein Azure Monitoring Agent nicht mehr kommuniziert oder keine Daten sendet (z.B. basierend auf dem „Heartbeat”-Signal im Log Analytics Workspace).
- DCR-Management: Verwenden Sie Azure Policy oder ARM-Templates, um DCRs konsistent in Ihrer Umgebung bereitzustellen und zu verwalten. Das minimiert manuelle Fehler.
- Test-DCRs: Führen Sie neue oder geänderte DCRs zuerst in einer Testumgebung ein, um deren Funktionalität zu validieren, bevor Sie sie auf Produktivsystemen anwenden.
- Agent-Updates: Halten Sie den Azure Monitoring Agent über Azure-Erweiterungen oder andere Update-Mechanismen aktuell, um von den neuesten Features und Bugfixes zu profitieren.
- Dokumentation: Dokumentieren Sie Ihre DCRs, deren Zweck und die zugewiesenen VMs.
Zusammenfassung und Nächste Schritte
Die Fehlersuche bei fehlenden Performance-Metriken vom Azure Monitoring Agent erfordert einen systematischen Ansatz. Beginnen Sie immer mit den grundlegenden Prüfungen des Agent-Status und der Konnektivität. Tauchen Sie dann tief in die Data Collection Rules ein, da diese die Datensammlung steuern. Die Analyse der Agent-Logs ist oft der Schlüssel zur Entdeckung der eigentlichen Ursache.
Sollten Sie nach Durchführung all dieser Schritte immer noch keine Lösung finden, ist es ratsam, den Microsoft Azure Support zu kontaktieren. Stellen Sie sicher, dass Sie alle gesammelten Informationen – Agent-Logs, DCR-Konfiguration, Fehlermeldungen – bereithalten, um den Supportprozess zu beschleunigen.
Ein funktionierendes Monitoring ist das Rückgrat jeder stabilen Cloud-Infrastruktur. Nehmen Sie das Schweigen Ihres Azure Monitoring Agents nicht auf die leichte Schulter – dieser Guide sollte Ihnen die Werkzeuge an die Hand geben, um schnell wieder vollen Einblick in die Leistung Ihrer Azure-Ressourcen zu erhalten.