Leitfaden zur Problembehandlung für den Azure Monitor-Agent auf virtuellen Linux-Computern sowie für Skalierungsgruppen

Übersicht über Azure Monitor Agent

Bevor Sie weiter lesen, müssen Sie mit Azure Monitor Agent und Datensammlungsregeln vertraut sein.

Begriff

Grundlegende Schritte zur Problembehandlung

Führen Sie die folgenden Schritte aus, um die neueste Version des auf Ihrem virtuellen Linux-Computer ausgeführten Azure Monitor-Agents zu beheben:

1. Überprüfen Sie die Voraussetzungen hier sorgfältig.

2. Überprüfen Sie, ob die Erweiterung erfolgreich installiert und bereitgestellt wurde, wodurch die Agent-Binärdateien auf Ihrem Computer installiert werden:

   1. Öffnen Sie das Azure-Portal > und wählen Sie Ihre virtuelle Maschine > Öffnen Sie Einstellungen : Erweiterungen + Anwendungen aus dem Bereich auf der linken Seite > "AzureMonitorLinuxAgent" sollte mit dem Status "Bereitstellung erfolgreich" angezeigt werden.

   2. Wenn die Erweiterung nicht aufgeführt ist, überprüfen Sie, ob der Computer Azure erreichen kann, und suchen Sie die Erweiterung, die mit dem folgenden Befehl installiert werden soll:

      az vm extension image list-versions --location <machine-region> --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor
      

   3. Warten Sie zehn bis 15 Minuten, da sich die Erweiterung möglicherweise in einem Übergangsstatus befindet. Wenn sie immer noch nicht wie zuvor beschrieben angezeigt wird, deinstallieren Sie die Erweiterung, und installieren Sie sie erneut.

   4. Überprüfen Sie, ob auf Ihrem Computer Fehler in den Erweiterungsprotokollen angezeigt werden, die sich unter /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ befinden.

3. Vergewissern Sie sich, dass der Agent ausgeführt wird:

   1. Überprüfen Sie mithilfe der folgenden Abfrage, ob der Agent Heartbeatprotokolle an den Log Analytics-Arbeitsbereich sendet. Überspringen Sie, wenn 'Benutzerdefinierte Metriken' das einzige Ziel in der Datensammlungsregel (DATA Collection Rule, DCR) ist:

      Heartbeat | where Category == "Azure Monitor Agent" and Computer == "<computer-name>" | take 10
      

   2. Überprüfen, ob der Agentdienst ausgeführt wird

      systemctl status azuremonitoragent
      

   3. Überprüfen Sie, ob Kernprotokolle des Agents auf Ihrem Computer (unter /var/opt/microsoft/azuremonitoragent/log/mdsd.*) Fehler enthalten.

4. Überprüfen Sie, ob der DCR vorhanden ist und dem virtuellen Computer zugeordnet ist:

   1. Wenn Sie Log Analytics Arbeitsbereich als Ziel verwenden, überprüfen Sie, ob DCR in demselben physischen Bereich wie der Log Analytics Arbeitsbereich vorhanden ist.
   2. Öffnen Sie das Azure-Portal > Wählen Sie Ihre Datensammlungsregel > Öffnen Sie Konfiguration: Ressourcen aus dem Bereich auf der linken Seite > Sie sollten hier die aufgelistete virtuelle Maschine sehen.
   3. Wenn diese Option nicht aufgeführt ist, wählen Sie "Hinzufügen" und dann ihren virtuellen Computer aus der Ressourcenauswahl aus. Wiederholen Sie diesen Schritt für alle Datensammlungsregeln.

5. Überprüfen Sie, ob der Agent die zugeordneten DCR(en) aus dem AMCS-Dienst herunterladen konnte:

   1. Überprüfen Sie, ob die neueste Datensammlungsregel an den folgenden Speicherort heruntergeladen wurde: /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/.

6. Wenn das Verzeichnis oder die Dateien fehlen:

   1. Der Azure Monitor Agent konnte die Datensammlungsregel (Data Collection Rule, DCR) nicht aus dem Azure Monitor Konfigurationsdienst (AMCS) herunterladen.
   2. Dies weist in der Regel auf eine der folgenden Werte hin:
   3. Der virtuelle Computer ist keinem DCR zugeordnet.
   4. Der virtuelle Computer kann aufgrund von Netzwerk- oder DNS-Einschränkungen nicht zu AMCS gelangen.
   5. Der Azure Monitor Agent-Dienst läuft nicht oder ist beim Start fehlgeschlagen.

7. Führen Sie die folgenden Aktionen aus:

   1. Bestätigen Sie, dass der DCR dem virtuellen Computer zugeordnet ist:

      • Azure Portal→ Datensammlungsregeln → Wählen Sie Ihren DCR → Resources
      • Stellen Sie sicher, dass der virtuelle Computer in der Liste angezeigt wird.

   2. Überprüfen Sie die ausgehende Konnektivität der VM:

      curl -v https://global.handler.control.monitor.azure.com
      

   3. Eine erfolgreiche TLS-Verbindung bestätigt, dass der virtuelle Computer AMCS erreichen kann.

   4. Starten Sie den Agent neu:

      sudo systemctl restart azuremonitoragent
      sudo systemctl status azuremonitoragent
      

   5. Überprüfen Sie die Agenten-Fehlerprotokolle:

      sudo tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.err
      

8. Wie eine gültige Konfigurationsdatei aussieht:

   1. Jede Datei unter /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/ stellt eine geparste Daten-Sammlungsregel dar, die von Azure heruntergeladen wurde.

   2. Beispiel:

      ls /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/
      

   3. Ausgabe:

      dcr_1a2b3c4d.json
      dcr_5e6f7g8h.json
      

   4. Prüfen einer Datei:

      cat /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/dcr_1a2b3c4d.json
      

   5. Typische Inhalte sind:

      {
      "dataSources": {
      "syslog": [
      {
      "facilityNames": ["daemon"],
      "logLevels": ["Info", "Warning", "Error"]
      }
      ]
      },
      "destinations": {
      "logAnalytics": [
      {
      "workspaceResourceId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>"
      }
      ]
      }
      }
      

Wenn diese Dateien leer, fehlen oder falsch formatiert sind, sammelt oder lädt der Agent keine Daten hoch.

Probleme beim Sammeln von Syslog

Weitere Informationen zum Beheben von Syslog-Problemen mit Azure Monitor Agent finden Sie unter here.

• Die QoS-Datei /var/opt/microsoft/azuremonitoragent/log/mdsd.qos (Quality of Service) enthält 15-minütige, CSV-formatierte Aggregationen der verarbeiteten Ereignisse sowie Informationen zur Menge der verarbeiteten Syslog-Ereignisse im angegebenen Zeitrahmen. Diese Datei ist nützlich, um Verluste beim Einlesen von Syslog-Ereignissen nachzuverfolgen.

  Das folgende Beispiel zeigt, dass der Agent in den 15 Minuten zuvor 2022-02-28T19:55:23.5432920Z77 Syslog-Ereignisse mit Informationen zur Einrichtungsdaemon und -ebene empfangen und 77 der genannten Ereignisse an die Uploadaufgabe gesendet hat. Darüber hinaus hat die Agent-Uploadaufgabe 77 Nachrichten vom Typ „daemon.info“ empfangen und alle 77 erfolgreich hochgeladen.

  #Time: 2022-02-28T19:55:23.5432920Z
  #Fields: Operation,Object,TotalCount,SuccessCount,Retries,AverageDuration,AverageSize,AverageDelay,TotalSize,TotalRowsRead,TotalRowsSent
  ...
  MaRunTaskLocal,daemon.debug,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.info,15,15,0,60000,46.2,0,693,77,77
  MaRunTaskLocal,daemon.notice,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.warning,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.error,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.critical,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.alert,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.emergency,15,15,0,60000,0,0,0,0,0
  ...
  MaODSRequest,https://e73fd5e3-ea2b-4637-8da0-5c8144b670c8_LogManagement,15,15,0,455067,476.467,0,7147,77,77
  

Schritte zur Problembehandlung

1. Überprüfen Sie zunächst die allgemeinen Schritte zur Problembehandlung bei Linux AMA . Wenn der Agent Heartbeats sendet, fahren Sie mit Schritt 2 fort.

2. Die analysierte Konfiguration wird unter /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/ gespeichert. Vergewissern Sie sich, dass die Syslog-Sammlung definiert ist und die Protokollziele den Protokollzielen entsprechen, die über die Benutzeroberfläche bzw. per JSON-Code für die Datensammlungsregeln erstellt wurden.

   1. Ist dies der Fall, fahren Sie mit Schritt 3 fort. Falls nicht, befindet sich das Problem im Konfigurationsworkflow.
   2. Untersuchen Sie die Dateien mdsd.err, mdsd.warn und mdsd.info unter /var/opt/microsoft/azuremonitoragent/log auf mögliche Konfigurationsfehler.

3. Überprüfen Sie das Layout des Syslog-Sammlungsworkflows, um sicherzustellen, dass alle erforderlichen Komponenten vorhanden und zugänglich sind:

   1. Stellen Sie für rsyslog-Benutzer sicher, dass die Datei /etc/rsyslog.d/10-azuremonitoragent.conf vorhanden, nicht leer und für den rsyslog-Daemon (Syslog-Benutzer) zugänglich ist.
      1. Überprüfen Sie Ihre rsyslog-Konfiguration bei /etc/rsyslog.conf und /etc/rsyslog.d/*, um festzustellen, ob Sie Eingaben haben, die an ein nicht standardmäßiges Regelset gebunden sind, da Nachrichten von diesen Eingaben nicht an Azure Monitor Agent weitergeleitet werden. Beispielsweise werden Nachrichten aus einer Eingabe, die mit einem nicht standardmäßigen Regelsatz wie input(type="imtcp" port="514" ruleset="myruleset") konfiguriert ist, nicht weitergeleitet.
   2. Stellen Sie für syslog-ng-Benutzer sicher, dass die Datei /etc/syslog-ng/conf.d/azuremonitoragent.conf vorhanden, nicht leer und für den syslog-ng-Daemon (Syslog-Benutzer) zugänglich ist.
   3. Stellen Sie sicher, dass die Datei /run/azuremonitoragent/default_syslog.socket vorhanden und für rsyslog bzw. syslog-ng zugänglich ist.
   4. Vergewissern Sie sich, dass die Warteschlange des Syslog-Daemons nicht überläuft, was dazu führt, dass der Upload nicht erfolgreich ist. Eine entsprechende Anleitung finden Sie hier: rsyslog-Daten werden nicht hochgeladen, da für den AMA unter Linux nicht genügend Speicherplatz verfügbar ist.

4. Zum weiteren Debuggen der Syslog-Ereigniserfassung können Sie das Ablaufverfolgungsflag -T 0x2002 am Ende von MDSD_OPTIONS in der Datei /etc/default/azuremonitoragent anfügen und den Agent neu starten:

   export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"
   

5. Nachdem das Problem bei aktiviertem Ablaufverfolgungsflag reproduziert wurde, finden Sie in /var/opt/microsoft/azuremonitoragent/log/mdsd.info weitere Debuginformationen. Suchen Sie in der Datei nach der möglichen Ursache für das Syslog-Sammlungsproblem (beispielsweise Analyse-, Verarbeitungs-, Konfigurations- oder Uploadfehler).

   Warnung

   Stellen Sie sicher, dass die Einstellung für das Ablaufverfolgungskennzeichen -T 0x2002 nach der Debugsitzung entfernt wird, da sie viele Ablaufverfolgungsanweisungen generiert, die den Datenträger schneller füllen können oder die visuelle Analyse der Protokolldatei erschweren.

Behandeln von Problemen auf einem Arc-fähigen Server

Wenn nach der Überprüfung der grundlegenden Problembehandlungsschritte der Azure Monitor-Agent keine Protokolle ausgibt oder 'Fehler beim Abrufen des MSI-Tokens vom IMDS-Endpunkt' in der /var/opt/microsoft/azuremonitoragent/log/mdsd.err Protokolldatei gefunden werden, ist der syslog Benutzer wahrscheinlich kein Mitglied der Gruppe himds. Fügen Sie den Benutzer „syslog“ zur Benutzergruppe „himds“ hinzu, wenn der Benutzer kein Mitglied dieser Gruppe ist. Erstellen Sie bei Bedarf den Benutzer „syslog“ und die Gruppe „syslog“, und stellen Sie sicher, dass sich der Benutzer in dieser Gruppe befindet. Weitere Informationen zu den Authentifizierungsanforderungen für Azure Arc-fähige Server finden Sie hier.

Eine vollständige Liste der Linux-Benutzerkonten, die der Azure Monitor Agent und Azure Arc erstellen, finden Sie unter Linux-Benutzerkonten, die während der Installation erstellt wurden.

Probleme mit automatischen Aktualisierungen bei Virtual Machine Scale Sets

Wenn Sie das automatische Erweiterungsupgrade für ein Skalierungsset von AzureMonitorLinuxAgent virtuellen Maschinen aktivieren, aktualisiert das Flag zuerst das Modell des Skalierungssets. Wenn die Upgraderichtlinie Ihres Skalierungssatzes auf Manuell festgelegt ist, wird diese Änderung erst an vorhandene Instanzen weitergegeben, wenn Sie die Modellaktualisierung anwenden.

Sie können das neueste Modell im Azure Portal oder programmgesteuert anwenden.

az vmss update-instances -g <resource-group> -n <vmss> --instance-ids "*"

Update-AzVmssInstance -ResourceGroupName <resource-group> -VMScaleSetName <vmss> -InstanceId "*"

Dadurch wird das aktuelle Skalierungsmodell (einschließlich des aktualisierten enableAutomaticUpgrade Flags) auf die ausgewählten Instanzen angewendet.

az vmss update -g <resource-group> -n <vmss> --set upgradePolicy.mode=Rolling

Wenn bestimmte virtuelle Computer immer noch nicht aktualisiert werden, überprüfen Sie den Instanzschutz (schutz vor Skalierungsgruppenaktionen), und deaktivieren Sie ihn, falls festgelegt.

Nächste Schritte

• Verwenden Sie das Problembehandlungs-Tool für den Azure Monitor Agent für Linux