Freigeben über

Anleitung zur Syslog-Problembehandlung für den Azure Monitor-Agent für Linux

  • Artikel

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, deren Dienstende (End-of-Life, EOL) ansteht. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS End-of-Life-Leitfaden.

Übersicht über die Linux-Syslog-Sammlung des Azure Monitor-Agents und die unterstützten RFC-Standards:

  • Der Azure Monitor-Agent installiert während des Installationsprozesses eine Ausgabekonfiguration für den Syslog-Daemon des Systems. Die Konfigurationsdatei gibt an, wie Ereignisse zwischen dem Syslog-Daemon und dem Azure Monitor-Agent übermittelt werden.
  • Bei rsyslog (Großteil der Linux-Distributionen) wird die Konfigurationsdatei /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf verwendet. Bei syslog-ng wird die Konfigurationsdatei /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf verwendet.
  • Der Azure Monitor-Agent lauscht an einem TCP-Port, um Ereignisse von rsyslog / syslog-ng zu empfangen. Der Port für diese Kommunikation wird bei /etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port protokolliert.

    Hinweis

    Vor der Version 1.28 des Azure Monitor-Agent wurde ein Unix-Domain-Socket anstelle eines TCP-Ports verwendet, um Ereignisse von rsyslog zu empfangen. omfwd Ausgabemodul in rsyslog bietet Spooling- und Wiederholungsmechanismen für eine verbesserte Zuverlässigkeit.

  • Der Syslog-Daemon verwendet Warteschlangen, wenn die Erfassung des Azure Monitor-Agents verzögert oder der Azure Monitor-Agent nicht erreichbar ist.
  • Der Azure Monitor-Agent erfasst Syslog-Ereignisse über den zuvor erwähnten Socket und filtert sie basierend auf der Kombination von Einrichtung und Schweregrad aus der Konfiguration der Datensammlungsregel (Data Collection Rule, DCR) unter /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/. Alle facility oder severity, die in der DCR nicht vorhanden sind, werden verworfen.
  • Der Azure Monitor-Agent versucht, Ereignisse im Einklang mit RFC3164 und RFC5424 zu parsen. Er weiß auch, wie die auf dieser Website aufgeführten Nachrichtenformate geparst werden.
  • Der Azure Monitor-Agent identifiziert den Zielendpunkt für Syslog-Ereignisse aus der DCR-Konfiguration und versucht, die Ereignisse hochzuladen.

    Hinweis

    Der Azure Monitor-Agent verwendet standardmäßig lokale Persistenz. Alle von rsyslog oder syslog-ng erhaltenen Ereignisse werden unter /var/opt/microsoft/azuremonitoragent/events in die Warteschlange gestellt, wenn sie nicht hochgeladen werden können.

Probleme

Möglicherweise treten die folgenden Probleme auf.

Rsyslog-Daten werden aufgrund eines Problems mit vollem Speicherplatz im Azure Monitor-Agent für Linux nicht hochgeladen

Die nächsten Abschnitte beschreiben das Problem.

Symptom

Syslog-Daten werden nicht hochgeladen: Wenn Sie Fehlerprotokolle unter /var/opt/microsoft/azuremonitoragent/log/mdsd.err überprüfen, sehen Sie Einträge zu Fehler beim Einfügen des Elements in den lokalen persistenten Speicher… Kein Speicherplatz mehr auf dem Gerät, ähnlich wie im folgenden Codeausschnitt:

2021-11-23T18:15:10.9712760Z: Error while inserting item to Local persistent store syslog.error: IO error: No space left on device: While appending to file: /var/opt/microsoft/azuremonitoragent/events/syslog.error/000555.log: No space left on device

Ursache

Der Azure Monitor-Agent für Linux puffert Ereignisse zu /var/opt/microsoft/azuremonitoragent/events vor der Erfassung. Bei einer Standardinstallation des Azure Monitor-Agents für Linux benötigt dieses Verzeichnis im Leerlauf ca. 650 MB Speicherplatz. Die Größe auf dem Datenträger erhöht sich bei anhaltender Protokollierungslast. Das Verzeichnis wird etwa alle 60 Sekunden bereinigt und wieder auf ~650 MB reduziert, wenn die Last wieder in den Leerlauf zurückkehrt.

Bestätigen des Problems eines vollen Datenträgers

Der Befehl df zeigt, dass auf /dev/sda1 fast kein Platz mehr vorhanden ist, wie in der folgenden Ausgabe zu sehen ist. Beachten Sie, dass Sie das Zeilenelement untersuchen sollten, das mit dem Protokollverzeichnis korreliert (z. B. /var/log, /var oder /).

   df -h

Filesystem Size  Used Avail Use% Mounted on
udev        63G     0   63G   0% /dev
tmpfs       13G  720K   13G   1% /run
/dev/sda1   29G   29G  481M  99% /
tmpfs       63G     0   63G   0% /dev/shm
tmpfs      5.0M     0  5.0M   0% /run/lock
tmpfs       63G     0   63G   0% /sys/fs/cgroup
/dev/sda15 105M  4.4M  100M   5% /boot/efi
/dev/sdb1  251G   61M  239G   1% /mnt
tmpfs       13G     0   13G   0% /run/user/1000

Sie können den Befehl du verwenden, um den Datenträger zu überprüfen und so zu ermitteln, welche Dateien dazu führen, dass der Datenträger voll ist. Beispiel:

   cd /var/log
   du -h syslog*

6.7G    syslog
18G     syslog.1

In einigen Fällen meldet du möglicherweise keine großen Dateien oder Verzeichnisse. Es könnte sein, dass eine als (gelöscht) markierte Datei den Speicherplatz beansprucht. Dieser Fall kann eintreten, wenn ein anderer Prozess versucht hat, eine Datei zu löschen, aber ein Prozess mit dieser Datei noch geöffnet ist. Sie können den Befehl lsof verwenden, um auf solche Dateien zu überprüfen. Im folgenden Beispiel sehen wir, dass /var/log/syslog als gelöscht markiert ist, aber 3,6 GB Speicherplatz benötigt. Die Datei wurde nicht gelöscht, da sie für einen Prozess mit PID 1484 immer noch geöffnet ist.

   sudo lsof +L1

COMMAND   PID   USER   FD   TYPE DEVICE   SIZE/OFF NLINK  NODE NAME
none      849   root  txt    REG    0,1       8632     0 16764 / (deleted)
rsyslogd 1484 syslog   14w   REG    8,1 3601566564     0 35280 /var/log/syslog (deleted)

Rsyslog-Standardkonfiguration protokolliert alle Einrichtungen in „/var/log/“

Bei einigen beliebten Distributionen (beispielsweise Ubuntu 18.04 LTS) wird rsyslog mit einer Standardkonfigurationsdatei (/etc/rsyslog.d/50-default.conf) ausgeliefert, welche Ereignisse von fast allen Einrichtungen auf den Datenträger unter /var/log/syslogprotokolliert. Syslog-Ereignisse für die RedHat/CentOS-Familie werden unter /var/log/ gespeichert werden, aber in einer anderen Datei: /var/log/messages.

Der Azure Monitor-Agent ist nicht darauf angewiesen, dass Syslog-Ereignisse unter /var/log/ protokolliert werden. Stattdessen wird der rsyslog-Dienst so konfiguriert, dass er Ereignisse über einen TCP-Port direkt an den azuremonitoragent-Dienstprozess (mdsd) weiterleitet.

Abhilfe: Entfernen von Einrichtungen mit hohem Volumen aus „/etc/rsyslog.d/50-default.conf“

Wenn Sie ein hohes Protokollvolumen über rsyslog senden und Ihr System zum Protokollieren von Ereignissen für diese Einrichtungen eingerichtet ist, sollten Sie die rsyslog-Standardkonfiguration ändern, um die Protokollierung und Speicherung unter /var/log/ zu vermeiden. Die Ereignisse für diese Einrichtung werden weiterhin an den Azure Monitor-Agent weitergeleitet, da rsyslog eine andere Konfiguration für die Weiterleitung verwendet, die unter /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf platziert ist.

  1. Um beispielsweise zu verhindern, dass local4-Ereignisse unter /var/log/syslog oder /var/log/messages protokolliert werden, ändern Sie diese Zeile in der /etc/rsyslog.d/50-default.conf für diesem Codeschnipsel:

    *.*;auth,authpriv.none          -/var/log/syslog

    Zu diesem Codeschnipsel (fügen Sie local4.none; hinzu):

    *.*;local4.none;auth,authpriv.none          -/var/log/syslog

  2. sudo systemctl restart rsyslog