Behandeln von Problemen mit dem Log Analytics-Agent für Linux

  • Artikel

Dieser Artikel bietet Unterstützung bei der Problembehandlung von Fehlern, die beim Log Analytics-Agent für Linux in Azure Monitor auftreten können.

Log Analytics-Problembehandlungstool

Das Problembehandlungstool für den Log Analytics-Agent für Linux ist ein Skript, das für die Ermittlung und Diagnose von Problemen mit dem Log Analytics-Agent konzipiert ist. Es ist bei der Installation des Agents automatisch enthalten. Das Ausführen des Tools sollte der erste Schritt bei der Diagnose eines Problems sein.

Verwenden des Tools zur Problembehandlung

Um das Problembehandlungstool auszuführen, fügen Sie auf einem Computer mit dem Log Analytics-Agent den folgenden Befehl in ein Terminalfenster ein:

sudo /opt/microsoft/omsagent/bin/troubleshooter

Manuelle Installation

Das Problembehandlungstool ist bei der Installation des Log Analytics-Agents automatisch enthalten. Wenn bei der Installation ein beliebiger Fehler auftritt, können Sie das Tool auch manuell installieren:

  1. Stellen Sie sicher, dass der GNU Project Debugger (GDB) auf dem Computer installiert ist, da die Problembehandlung darauf basiert.
  2. Kopieren Sie das Problembehandlungspaket auf Ihren Computer: wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. Entpacken Sie das Paket: tar -xzvf omsagent_tst.tar.gz
  4. Führen Sie die manuelle Installation aus: sudo ./install_tst

Behandelte Szenarien

Das Problembehandlungstool überprüft die folgenden Szenarien:

  • Der Agent ist fehlerhaft, Heartbeat funktioniert nicht ordnungsgemäß.
  • Der Agent startet nicht, oder keine Verbindung mit Log Analytics.
  • Das Agent-Syslog funktioniert nicht.
  • Der Agent weist hohe CPU- oder Arbeitsspeicherauslastung auf.
  • Beim Agent treten Installationsprobleme auf.
  • Die benutzerdefinierten Agent-Protokolle funktionieren nicht.
  • Die Agent-Protokolle können nicht erfasst werden.

Weitere Informationen finden Sie in der Dokumentation zum Problembehandlungstool auf GitHub.

Hinweis

Führen Sie das Protokollsammler-Tool aus, wenn ein Problem auftritt. Wenn unserem Supportteam von Anfang an die Protokolle zur Verfügung stehen, lässt sich das Problem schneller beheben.

Bereinigen und erneutes Installieren des Linux-Agents

Eine saubere Neuinstallation des Agent behebt die meisten Probleme. Dieser Vorgang kann der erste Vorschlag unseres Supportteams sein, um den Agent in einen fehlerfreien Zustand zu versetzen. Wenn Sie das Problembehandlungstool und das Protokollsammler-Tool ausführen und eine saubere Neuinstallation versuchen, können Probleme schneller gelöst werden.

  1. Laden Sie das Skript zur endgültigen Löschung herunter:

    $ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh

  2. Führen Sie das Skript zur endgültigen Löschung (mit sudo-Berechtigungen) aus:

    $ sudo sh purge_omsagent.sh

Wichtige Protokollspeicherorte und das Protokollsammler-Tool

Datei `Path`
Protokolldatei des Log Analytics-Agents für Linux /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Konfigurationsprotokolldatei des Log Analytics-Agents für Linux /var/opt/microsoft/omsconfig/omsconfig.log

Wir empfehlen Ihnen, für die Problembehandlung oder vor dem Übermitteln eines GitHub-Problems wichtige Protokolle mit unserem Protokollsammler-Tool abzurufen. Weitere Informationen zum Tool und zur Ausführung finden Sie unter OMS Linux Agent Log Collector (OMS Linux-Agent-Protokollsammler).

Wichtige Konfigurationsdateien

Category Dateispeicherort
syslog /etc/syslog-ng/syslog-ng.conf oder /etc/rsyslog.conf oder /etc/rsyslog.d/95-omsagent.conf
Leistung, Nagios, Zabbix, Log Analytics-Ausgabe und allgemeiner Agent /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
Zusätzliche Konfigurationen /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Hinweis

Änderungen an den Konfigurationsdateien für Leistungsindikatoren und Syslog werden überschrieben, wenn die Sammlung für Ihren Arbeitsbereich im Azure-Portal über Agent-Konfiguration konfiguriert wird. Um die Konfiguration für alle Agents zu deaktivieren, deaktivieren Sie die Sammlung unter Verwaltung von Agent einer Vorgängerversion. Führen Sie für einen einzelnen Agent das folgende Skript aus:

sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable && sudo rm /etc/opt/omi/conf/omsconfig/configuration/Current.mof* /etc/opt/omi/conf/omsconfig/configuration/Pending.mof*

Codes für Installationsfehler

Fehlercode Bedeutung
NOT_DEFINED Da die erforderlichen Abhängigkeiten nicht installiert sind, wird das Plug-In „auoms auditd“ nicht installiert. Fehler bei Installation „auoms“. Installieren Sie das Paket „auditd“.
2 Für das Shellbündel wurde eine ungültige Option angegeben. Führen Sie sudo sh ./omsagent-*.universal*.sh --help aus, um Informationen zur Verwendung anzuzeigen.
3 Für das Shellbündel wurde keine Option angegeben. Führen Sie sudo sh ./omsagent-*.universal*.sh --help aus, um Informationen zur Verwendung anzuzeigen.
4 Ungültiger Pakettyp oder ungültige Proxyeinstellungen. Die omsagent-rpm.sh-Pakete können nur auf RPM-basierten Systemen installiert werden. Die omsagent-deb.sh-Pakete können nur auf Debian-basierten Systemen installiert werden. Sie sollten das universelle Installationsprogramm des aktuellen Release verwenden. Überprüfen Sie auch Ihre Proxyeinstellungen.
5 Das Shellbündel muss als Root-Benutzer ausgeführt werden, oder während des Onboardings wurde ein 403-Fehler zurückgegeben. Führen Sie den Befehl mit sudo aus.
6 Ungültige Paketarchitektur, oder während des Onboardings wurde ein 200-Fehler zurückgegeben. Die omsagent-*x64.sh-Pakete können nur auf 64-Bit-Systemen installiert werden. Die omsagent-*x86.sh-Pakete können nur auf 32-Bit-Systemen installiert werden. Laden Sie das richtige Paket für Ihre Architektur aus der aktuellen Version herunter.
17 Fehler bei der Installation des OMS-Pakets. Suchen Sie in der Ausgabe des Befehls nach der Grundursache des Fehlers.
18 Fehler bei der Installation des OMSConfig-Pakets. Suchen Sie in der Ausgabe des Befehls nach der Grundursache des Fehlers.
19 Fehler bei der Installation des OMI-Pakets. Suchen Sie in der Ausgabe des Befehls nach der Grundursache des Fehlers.
20 Fehler bei der Installation des SCX-Pakets. Suchen Sie in der Ausgabe des Befehls nach der Grundursache des Fehlers.
21 Fehler bei der Installation von Anbieterkits. Suchen Sie in der Ausgabe des Befehls nach der Grundursache des Fehlers.
22 Fehler bei der Installation des gebündelten Pakets. Suchen Sie in der Ausgabe des Befehls nach der Grundursache des Fehlers.
23 Das SCX- oder OMI-Paket ist bereits installiert. Verwenden Sie --upgrade anstelle von --install, um das Shellbündel zu installieren.
30 Interner Bündelfehler. Melden Sie ein GitHub-Problem mit Details aus der Ausgabe.
55 Nicht unterstützte OpenSSL-Version, oder die Verbindung mit Azure Monitor kann nicht hergestellt werden, oder dpkg ist gesperrt, oder das Programm cURL fehlt.
61 Die Python-ctypes-Bibliothek fehlt. Installieren Sie die Python-Bibliothek bzw. das Python-Paket ctypes (python-ctypes).
62 Das Programm „tar“ fehlt. Installieren Sie tar.
63 Das Programm „sed“ fehlt. Installieren Sie sed.
64 Das Programm „cURL“ fehlt. Installieren Sie „cURL“.
65 Das Programm „gpg“ fehlt. Installieren Sie „gpg“.

Codes für Onboardingfehler

Fehlercode Bedeutung
2 Im omsadmin-Skript wurde eine ungültige Option angegeben. Führen Sie sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h aus, um Informationen zur Verwendung anzuzeigen.
3 Im omsadmin-Skript wurde eine ungültige Konfiguration angegeben. Führen Sie sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h aus, um Informationen zur Verwendung anzuzeigen.
4 Im omsadmin-Skript wurde ein ungültiger Proxy angegeben. Überprüfen Sie den Proxy, und lesen Sie die Dokumentation zur Verwendung eines HTTP-Proxys.
5 HTTP-Fehler 403 von Azure Monitor empfangen. Details finden Sie in der vollständigen Ausgabe des omsadmin-Skripts.
6 Von 200 abweichender HTTP-Fehler von Azure Monitor empfangen. Details finden Sie in der vollständigen Ausgabe des omsadmin-Skripts.
7 Verbindung mit Azure Monitor nicht möglich. Details finden Sie in der vollständigen Ausgabe des omsadmin-Skripts.
8 Fehler beim Onboarding im Log Analytics-Arbeitsbereich. Details finden Sie in der vollständigen Ausgabe des omsadmin-Skripts.
30 Interner Skriptfehler. Melden Sie ein GitHub-Problem mit Details aus der Ausgabe.
31 Fehler beim Generieren der Agent-ID. Melden Sie ein GitHub-Problem mit Details aus der Ausgabe.
32 Fehler beim Generieren von Zertifikaten. Details finden Sie in der vollständigen Ausgabe des omsadmin-Skripts.
33 Fehler beim Generieren der Metakonfiguration für omsconfig. Melden Sie ein GitHub-Problem mit Details aus der Ausgabe.
34 Das Skript zum Generieren der Metakonfiguration ist nicht vorhanden. Wiederholen Sie das Onboarding mit sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

Debugprotokollierung aktivieren

Debuggen mit dem OMS-Ausgabe-Plug-In

FluentD ermöglicht die Verwendung von Plug-In-spezifischen Protokolliergraden, sodass Sie verschiedene Protokollebenen für Ein- und Ausgaben festlegen können. Bearbeiten Sie zum Festlegen einer anderen Protokollebene für die OMS-Ausgabe die allgemeine Agent-Konfiguration unter /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Ändern Sie im OMS-Ausgabe-Plug-In vor dem Ende der Konfigurationsdatei die log_level-Eigenschaft von info in debug:

<match oms.** docker.**>
  type out_oms
  log_level debug
  num_threads 5
  buffer_chunk_limit 5m
  buffer_type file
  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
  buffer_queue_limit 10
  flush_interval 20s
  retry_limit 10
  retry_wait 30s
</match>

Mithilfe der Debugprotokollierung sehen Sie Batch-Uploads an Azure Monitor, getrennt nach Typ, Anzahl von Datenelementen und zum Senden benötigter Zeit.

Beispiel eines Debugprotokolls:

Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s

Ausführliche Ausgabe

Statt das OMS-Ausgabe-Plug-In zu verwenden, können Sie Datenelemente auch direkt an stdout ausgeben, was in der Protokolldatei des Log Analytics-Agents für Linux sichtbar ist.

Kommentieren Sie in der allgemeinen Agent-Konfigurationsdatei von Log Analytics unter /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf das OMS-Ausgabe-Plug-In aus, indem Sie vor jeder Zeile ein #-Zeichen hinzufügen:

#<match oms.** docker.**>
#  type out_oms
#  log_level info
#  num_threads 5
#  buffer_chunk_limit 5m
#  buffer_type file
#  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
#  buffer_queue_limit 10
#  flush_interval 20s
#  retry_limit 10
#  retry_wait 30s
#</match>

Heben Sie unter dem Ausgabe-Plug-In die Auskommentierung des folgenden Abschnitts auf, indem Sie das #-Zeichen vor jeder Zeile entfernen:

<match **>
  type stdout
</match>

Problem: Es ist keine Verbindung über den Proxy mit Azure Monitor möglich.

Mögliche Ursachen

  • Der während der Integration angegebene Proxy war falsch.
  • Die Dienstendpunkte für Azure Monitor und Azure Automation sind nicht in der genehmigten Liste in Ihrem Rechenzentrum enthalten.

Lösung

  1. Führen Sie das Onboarding in Azure Monitor mit dem Log Analytics-Agent für Linux erneut durch, indem Sie den folgenden Befehl mit aktivierter Option -v ausführen. Dies ermöglicht die ausführliche Ausgabe des Agents, der die Verbindung über den Proxy herstellt, an Azure Monitor: /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. Lesen Sie den Abschnitt Aktualisieren der Proxyeinstellungen, um sicherzustellen, dass der Agent ordnungsgemäß für die Kommunikation über einen Proxyserver konfiguriert wurde.

  3. Vergewissern Sie sich, dass die Endpunkte aus der Liste der Netzwerkfirewallanforderungen für Azure Monitor ordnungsgemäß auf eine Positivliste gesetzt wurden. Wenn Sie Azure Automation verwenden, sind oben auch Links zu den erforderlichen Schritten für die Netzwerkkonfiguration angegeben.

Problem: Beim Onboardingversuch erhalten Sie einen 403-Fehler.

Mögliche Ursachen

  • Datum und Uhrzeit auf dem Linux-Server sind falsch.
  • Die Arbeitsbereichs-ID und der Arbeitsbereichsschlüssel sind nicht korrekt.

Lösung

  1. Überprüfen Sie die Uhrzeit auf dem Linux-Server mit dem Befehl „date“. Wenn die Zeit ca. +/- 15 Minuten von der aktuellen Uhrzeit abweicht, tritt beim Onboarding ein Fehler auf. Aktualisieren Sie zur Behandlung dieser Situation das Datum und/oder die Zeitzone des Linux-Servers.
  2. Überprüfen Sie, ob die aktuelle Version des Log Analytics-Agents für Linux installiert ist. Die neueste Version benachrichtigt Sie nun darüber, ob der Onboardingfehler durch die Zeitabweichung verursacht wird.
  3. Führen Sie gemäß den Installationsanweisungen weiter oben in diesem Artikel das Onboarding erneut mit korrekten Daten für die Arbeitsbereichs-ID und den Arbeitsbereichsschlüssel durch.

Problem: In der Protokolldatei sind direkt nach der Integration die Fehler 500 und 404 enthalten.

Dies ist ein bekanntes Problem, das beim ersten Hochladen von Linux-Daten in einen Log Analytics-Arbeitsbereich auftritt. Gesendete Daten und die Ausführung des Diensts sind davon nicht betroffen.

Problem: OMI-Agent verwendet 100 % der CPU

Mögliche Ursachen

Eine Regression im nss-pem-Paket v1.0.3-5.el7 verursachte ein schwerwiegendes Leistungsproblem. Wir haben dieses Problem häufig in Redhat/CentOS 7.x-Distributionen beobachtet. Mehr über dieses Problem erfahren Sie unter 1667121 Performance-Regression in libcurl (Leistungsregression in libcurl).

Leistungsbezogene Fehler kommen nicht immer vor und sind nur schwer zu reproduzieren. Wenn ein solches Problem mit OMI-Agent auftritt, verwenden Sie das Skript omiHighCPUDiagnostics.sh, das bei Überschreitung eines bestimmten Schwellenwerts die Stapelüberwachung des OMI-Agents erfasst.

  1. Laden Sie das Skript herunter:
    wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

  2. Führen Sie für 24 Stunden Diagnose mit einem CPU-Schwellenwert von 30 % aus:
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. Die Aufrufliste wird in der omiagent_trace-Datei gesichert. Wenn Sie viele cURL- und NSS-Funktionsaufrufe feststellen, befolgen Sie diese Lösungsschritte.

Lösung

  1. Aktualisieren Sie das nss-pem-Paket auf v1.0.3-5.el7_6.1:
    sudo yum upgrade nss-pem

  2. Wenn nss-perm nicht für das Upgrade verfügbar ist (tritt größtenteils unter CentOS auf), stufen Sie cURL auf 7.29.0-46 herab. Wenn Sie versehentlich „yum-update“ ausführen, wird cURL auf 7.29.0-51 aktualisiert, und das Problem wird erneut auftreten:
    sudo yum downgrade curl libcurl

  3. OMI neu starten:
    sudo scxadmin -restart

Problem: Weitergeleitete Syslog-Nachrichten werden nicht angezeigt

Mögliche Ursachen

  • Die auf den Linux-Server angewendete Konfiguration ermöglicht keine Sammlung der gesendeten Facilities oder Protokollebenen.
  • Syslog wird nicht ordnungsgemäß zum Linux-Server weitergeleitet.
  • Die Anzahl pro Sekunde weitergeleiteter Nachrichten ist zu groß für die Basiskonfiguration des Log Analytics-Agents für Linux.

Lösung

  • Überprüfen Sie, ob die Konfiguration im Log Analytics-Arbeitsbereich für Syslog alle Facilities und die richtigen Protokollebenen enthält. Lesen Sie die Informationen zum Konfigurieren der Syslog-Sammlung im Azure-Portal.
  • Stellen Sie sicher, dass native Syslog-Messagingdaemons (rsyslog, syslog-ng) die weitergeleiteten Nachrichten empfangen können.
  • Überprüfen Sie die Firewall-Einstellungen auf dem Syslog-Server, um sicherzustellen, dass Nachrichten nicht blockiert werden.
  • Simulieren Sie mit dem Befehl logger eine Syslog-Nachricht an Log Analytics:
    logger -p local0.err "This is my test message"

Problem: Sie empfangen eine bereits in der omsagent-Protokolldatei verwendete Errno-Adresse

[error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224> wird in „omsagent.log“ angezeigt.

Mögliche Ursachen

Dieser Fehler weist darauf hin, dass die Linux-Diagnoseerweiterung (LAD) parallel zur Log Analytics-Linux-VM-Erweiterung installiert ist. Sie verwendet denselben Port für die Syslog-Datensammlung wie omsagent.

Lösung

  1. Führen Sie die folgenden Befehle als Root-Benutzer aus. Beachten Sie, dass 25224 ein Beispiel ist, und in Ihrer Umgebung möglicherweise eine andere von LAD verwendete Portnummer angezeigt wird.

    /opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229

sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf

    Anschließend müssen Sie die richtige rsyslogd- oder syslog_ng-Konfigurationsdatei bearbeiten und die LAD-bezogene Konfiguration ändern, um die Ausgabe an Port 25229 zu senden.

  2. Wenn die VM rsyslogd ausführt, muss die Datei /etc/rsyslog.d/95-omsagent.conf geändert werden (sofern diese vorhanden ist, andernfalls /etc/rsyslog). Wenn die VM syslog_ng ausführt, muss die Datei /etc/syslog-ng/syslog-ng.conf geändert werden.

  3. Starten Sie omsagent mit sudo /opt/microsoft/omsagent/bin/service_control restart neu.

  4. Starten Sie den Syslog-Dienst neu.

Problem: Sie können omsagent nicht mit der purge-Option deinstallieren

Mögliche Ursachen

  • Die Linux-Diagnoseerweiterung ist installiert.
  • Die Linux-Diagnoseerweiterung wurde installiert und deinstalliert, es wird aber weiterhin ein Fehler angezeigt, dass omsagent von mdsd verwendet wird und nicht entfernt werden kann.

Lösung

  1. Deinstallieren Sie die Linux-Diagnoseerweiterung.
  2. Entfernen Sie die Dateien der Linux-Diagnoseerweiterung vom Computer, sofern sie am folgenden Speicherort vorhanden sind: /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ und /var/opt/microsoft/omsagent/LAD/.

Problem: Es werden keine Nagios-Daten angezeigt

Mögliche Ursachen

  • Der omsagent-Benutzer besitzt keine Berechtigungen zum Lesen aus der Nagios-Protokolldatei.
  • Die Auskommentierung der Nagios-Quelle und des Nagios-Filters wurde in der Datei „omsagent.conf“ nicht aufgehoben.

Lösung

  1. Fügen Sie wie in diesen Anweisungen beschrieben einen omsagent-Benutzer mit der Berechtigung zum Lesen der Nagios-Datei hinzu.

  2. Vergewissern Sie sich in der allgemeinen Konfigurationsdatei des Log Analytics-Agents für Linux unter /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf, dass die Auskommentierung der Nagios-Quelle und des Nagios-Filters aufgehoben wurde.

    <source>
  type tail
  path /var/log/nagios/nagios.log
  format none
  tag oms.nagios
</source>

<filter oms.nagios>
  type filter_nagios_log
</filter>

Problem: Es werden keine Linux-Daten angezeigt

Mögliche Ursachen

  • Fehler beim Onboarding in Azure Monitor.
  • Die Verbindung mit Azure Monitor ist blockiert.
  • Die VM wurde neu gestartet.
  • Das OMI-Paket wurde manuell auf eine Version aktualisiert, die neuer ist als die vom „Log Analytics-Agent für Linux“-Paket installierte Version.
  • OMI wurde angehalten und blockiert dadurch den OMS-Agent.
  • Die DSC-Ressource protokolliert einen Fehler vom Typ Klasse nicht gefunden in der Protokolldatei omsconfig.log.
  • Daten des Log Analytics-Agents werden gesichert.
  • DSC protokolliert Aktuelle Konfiguration ist nicht vorhanden. Führen Sie den Befehl „Start-DscConfiguration“ mit dem Parameter „-Path“ aus, um eine Konfigurationsdatei festzulegen und zuerst eine aktuelle Konfiguration zu erstellen. in der Protokolldatei omsconfig.log, aber es ist keine Protokollmeldung zu PerformRequiredConfigurationChecks-Vorgängen vorhanden.

Lösung

  1. Installieren Sie alle Abhängigkeiten (z. B. das auditd-Paket).

  2. Vergewissern Sie sich, dass das Onboarding in Azure Monitor erfolgreich war, indem Sie überprüfen, ob die folgende Datei vorhanden ist: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Falls dies nicht der Fall ist, wiederholen Sie das Onboarding mithilfe der Anweisungen der omsadmin.sh-Befehlszeile.

  3. Gehen Sie bei der Verwendung eines Proxys gemäß den oben aufgeführten Schritten zur Proxyproblembehandlung vor.

  4. In einigen Azure-Verteilungssystemen wird der omid-OMI-Serverdaemon nach dem Neustart der VM nicht gestartet. Wenn dies der Fall ist, werden keine Daten zu Audit-, ChangeTracking- oder UpdateManagement-Lösungen angezeigt. Die Problemumgehung besteht darin, den OMI-Server durch Ausführen von sudo /opt/omi/bin/service_control restart manuell zu starten.

  5. Nachdem das OMI-Paket manuell auf eine neuere Version aktualisiert wurde, muss es manuell neu gestartet werden, damit der Log Analytics-Agent weiterhin funktioniert. Dieser Schritt ist für einige Distributionen erforderlich, bei denen der OMI-Server nach einem Upgrade nicht automatisch gestartet wird. Führen Sie sudo /opt/omi/bin/service_control restart aus, um den OMI-Server neu zu starten.

    In einigen Situationen kann der OMI-Server angehalten werden. Der OMS-Agent kann in den gesperrten Status wechseln und auf den OMI-Server warten. Dabei wird die gesamte Datensammlung blockiert. Der OMS-Agent-Prozess wird ausgeführt, es gibt jedoch keine Aktivitäten. Dies ist daran zu erkennen, dass in omsagent.log keine neuen Protokollzeilen (etwa gesendete Heartbeats) vorhanden sind. Starten Sie den OMI-Server mit sudo /opt/omi/bin/service_control restart neu, um den Agent wiederherzustellen.

  6. Falls ein DSC-Ressourcenfehler vom Typ Klasse nicht gefunden in der Datei „omsconfig.log“ angezeigt wird, führen Sie sudo /opt/omi/bin/service_control restart aus.

  7. In einigen Fällen, wenn der Log Analytics-Agent für Linux nicht mit Azure Monitor kommunizieren kann, werden Daten auf dem Agent bis zur vollständigen Puffergröße von 50 MB gesichert. Der Agent sollte mit dem folgenden Befehl neu gestartet werden: /opt/microsoft/omsagent/bin/service_control restart.

    Hinweis

    Dieses Problem wurde ab der Agent-Version 1.1.0-28 behoben.

    • Wenn in der Protokolldatei omsconfig.log nicht angezeigt wird, dass regelmäßig PerformRequiredConfigurationChecks-Vorgänge auf dem System ausgeführt werden, liegt möglicherweise ein Problem mit dem Cron-Auftrag/-Dienst vor. Stellen Sie sicher, dass der Cron-Auftrag unter /etc/cron.d/OMSConsistencyInvoker vorhanden ist. Führen Sie ggf. die folgenden Befehle aus, um den Cron-Auftrag zu erstellen:

      mkdir -p /etc/cron.d/
echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker

    • Stellen Sie außerdem sicher, dass der Cron-Dienst ausgeführt wird. Sie können service cron status unter Debian, Ubuntu und SUSE oder service crond status unter RHEL, CentOS und Oracle Linux verwenden, um den Status dieses Diensts zu überprüfen. Falls der Dienst nicht vorhanden ist, können Sie mit den folgenden Anweisungen die Binärdateien installieren und den Dienst starten:

      Ubuntu/Debian

      # To Install the service binaries
sudo apt-get install -y cron
# To start the service
sudo service cron start

      SUSE

      # To Install the service binaries
sudo zypper in cron -y
# To start the service
sudo systemctl enable cron
sudo systemctl start cron

      RHEL/CentOS

      # To Install the service binaries
sudo yum install -y crond
# To start the service
sudo service crond start

      Oracle Linux

      # To Install the service binaries
sudo yum install -y cronie
# To start the service
sudo service crond start

Problem: Wenn Sie die Sammlung über das Portal für Syslog oder Linux-Leistungsindikatoren konfigurieren, werden die Einstellungen nicht angewendet

Mögliche Ursachen

  • Der Log Analytics-Agent für Linux hat nicht die aktuelle Konfiguration übernommen.
  • Die geänderten Einstellungen im Portal wurden nicht angewendet.

Lösung

Hintergrund:omsconfig ist der Konfigurations-Agent für den Log Analytics-Agent für Linux, der alle fünf Minuten nach einer neuen im Portal erstellten Konfiguration sucht. Diese Konfiguration wird dann auf die Konfigurationsdateien des Log Analytics-Agents für Linux unter „/etc/opt/microsoft/omsagent/conf/omsagent.conf“ angewendet.

In einigen Fällen kann der Konfigurations-Agent für den Log Analytics-Agent für Linux möglicherweise nicht mit dem Portalkonfigurationsdienst kommunizieren. Dieses Szenario führt dazu, dass die neueste Konfiguration nicht angewendet wird.

  1. Überprüfen Sie, ob der omsconfig-Agent installiert ist, indem Sie dpkg --list omsconfig oder rpm -qi omsconfig ausführen. Falls der Agent nicht installiert ist, installieren Sie die aktuelle Version des Log Analytics-Agents für Linux.

  2. Überprüfen Sie, ob der omsconfig-Agent mit Azure Monitor kommunizieren kann, indem Sie folgenden Befehl ausführen: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Dieser Befehl gibt die Konfiguration zurück, die der Agent vom Dienst empfängt (einschließlich der Syslog-Einstellungen, Linux-Leistungsindikatoren und benutzerdefinierten Protokolle). Falls bei diesem Befehl ein Fehler auftritt, führen Sie den folgenden Befehl aus: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Dieser Befehl erzwingt die Kommunikation des omsconfig-Agents mit Azure Monitor und das Abrufen der aktuellen Konfiguration.

Problem: Es werden keine benutzerdefinierten Protokolldaten angezeigt

Mögliche Ursachen

  • Fehler beim Onboarding in Azure Monitor.
  • Die Einstellung Die nachstehende Konfiguration auf meine Linux-Server anwenden wurde nicht ausgewählt.
  • omsconfig hat nicht die aktuelle benutzerdefinierte Protokollkonfiguration aus dem Dienst übernommen.
  • Der Benutzer omsagent des Log Analytics-Agents für Linux kann nicht auf das benutzerdefinierte Protokoll zugreifen, weil seine Berechtigungen nicht ausreichen oder das Protokoll nicht gefunden wurde. Es werden möglicherweise die folgenden Fehler angezeigt:
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • Bekanntes Problem mit einer Racebedingung, das in Log Analytics-Agent für Linux Version 1.1.0-217 behoben wurde.

Lösung

  1. Vergewissern Sie sich, dass das Onboarding in Azure Monitor erfolgreich war, indem Sie überprüfen, ob die folgende Datei vorhanden ist: /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Falls dies nicht der Fall ist, führen Sie einen der folgenden Schritte aus:

    1. Wiederholen Sie das Onboarding mithilfe der Anweisungen der Befehlszeile „omsadmin.sh“.
    2. Vergewissern Sie sich im Azure-Portal unter Erweiterte Einstellungen, dass die Einstellung Apply the following configuration to my Linux Servers (Die nachstehende Konfiguration auf meine Linux-Server anwenden) aktiviert ist.

  2. Überprüfen Sie, ob der omsconfig-Agent mit Azure Monitor kommunizieren kann, indem Sie folgenden Befehl ausführen: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Dieser Befehl gibt die Konfiguration zurück, die der Agent vom Dienst empfängt (einschließlich der Syslog-Einstellungen, Linux-Leistungsindikatoren und benutzerdefinierten Protokolle). Falls bei diesem Befehl ein Fehler auftritt, führen Sie den folgenden Befehl aus: sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Dieser Befehl erzwingt die Kommunikation des omsconfig-Agents mit Azure Monitor und das Abrufen der aktuellen Konfiguration.

Hintergrund: Der Log Analytics-Agent für Linux wird nicht als privilegierter Benutzer root ausgeführt, sondern als Benutzer omsagent. In den meisten Fällen muss diesem Benutzer eine explizite Berechtigung erteilt werden, damit bestimmte Dateien gelesen werden können. Damit Benutzer omsagent die erforderliche Berechtigung bekommt, führen Sie die folgenden Befehle aus:

  1. Fügen Sie den Benutzer omsagent einer bestimmten Gruppe hinzu: sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. Gewähren Sie universellen Lesezugriff auf die erforderliche Datei: sudo chmod -R ugo+rx <FILE DIRECTORY>.

Im Log Analytics-Agent für Linux vor Version 1.1.0-217 besteht ein bekanntes Problem mit einer Racebedingung. Führen Sie nach der Aktualisierung auf den aktuellen Agent den folgenden Befehl aus, um die aktuelle Version des Ausgabe-Plug-Ins abzurufen: sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Problem: Sie versuchen, ein erneutes Onboarding in einem neuen Arbeitsbereich durchzuführen

Wenn Sie versuchen, für einen Agent ein erneutes Onboarding in einem neuen Arbeitsbereich durchzuführen, muss die Konfiguration des Log Analytics-Agents vor dem erneuten Onboarding bereinigt werden. Führen Sie zum Bereinigen der alten Konfiguration des Agents das Shellbündel mit --purge aus:

sudo sh ./omsagent-*.universal.x64.sh --purge

oder

sudo sh ./onboard_agent.sh --purge

Sie können nach Verwendung der --purge-Option mit dem erneuten Onboarding fortfahren.

Problem: Die Log Analytics-Agent-Erweiterung im Azure-Portal ist mit einem Fehlerstatus markiert: Fehler bei der Bereitstellung

Mögliche Ursachen

  • Der Log Analytics-Agent wurde aus dem Betriebssystem entfernt.
  • Der Log Analytics-Agent-Dienst ist nicht verfügbar, deaktiviert oder nicht konfiguriert.

Lösung

  1. Entfernen der Erweiterung aus dem Azure-Portal.
  2. Installieren Sie den Agent gemäß den Anweisungen.
  3. Starten Sie den Agent neu, indem Sie den folgenden Befehl ausführen:
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. Warten Sie einige Minuten, bis der Bereitstellungsstatus sich in Bereitstellung erfolgreich ändert.

Problem: On-Demand-Upgrade des Log Analytics-Agents

Mögliche Ursachen

Die Log Analytics-Agent-Pakete auf dem Host sind veraltet.

Lösung

  1. Das aktuelle Release finden Sie auf dieser GitHub-Seite.

  2. Laden Sie das Installationsskript herunter (1.4.2-124 ist eine Beispielversion):

    wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-124/omsagent-1.4.2-124.universal.x64.sh

  3. Aktualisieren Sie die Pakete, indem Sie sudo sh ./omsagent-*.universal.x64.sh --upgrade ausführen.

Problem: Bei der Installation tritt ein Fehler mit dem Hinweis auf, dass Python2 ctypes nicht unterstützen kann, obwohl Python3 verwendet wird

Mögliche Ursachen

Bei diesem bekannten Problem wird die Überprüfung der verwendeten Python-Version nicht erfolgreich ausgeführt, wenn die Sprache der VM nicht Englisch ist. Dies führt dazu, dass der Agent immer davon ausgeht, dass Python2 verwendet wird, und einen Fehler verursacht, wenn Python2 nicht vorhanden ist.

Lösung

Ändern Sie die Umgebungssprache der VM in Englisch:

export LANG=en_US.UTF-8