Guide de résolution des problèmes Syslog pour l’agent Azure Monitor pour Linux

  • Article

Attention

Cet article fait référence à CentOS, une distribution Linux proche de l’état EOL (End Of Life). Faites le point sur votre utilisation afin de vous organiser en conséquence. Pour plus d’informations, consultez les conseils d’aide relatifs à la fin de vie de CentOS.

Vue d’ensemble de la collection Syslog de l’agent Azure Monitor pour Linux et des normes RFC prises en charge :

  • L’agent Azure Monitor installe une configuration de sortie pour le démon Syslog système pendant le processus d’installation. Le fichier config spécifie le flux des événements entre le démon Syslog et l’agent Azure Monitor.
  • Pour rsyslog (la plupart des distributions Linux), le fichier config est /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf. Pour syslog-ng, le fichier config est /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf.
  • L’agent Azure Monitor écoute un port TCP pour recevoir les événements de rsyslog / syslog-ng. Le port de cette communication est journalisé à /etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port.

    Remarque

    Avant l’agent Azure Monitor version 1.28, il a utilisé un socket de domaine Unix au lieu du port TCP pour recevoir des événements de rsyslog. Le module de sortie omfwd dans rsyslog offre des mécanismes de mise en file d’attente et de nouvelle tentative pour améliorer la fiabilité.

  • Le démon Syslog utilise des files d’attente lorsque l’ingestion de l’agent Azure Monitor est retardée ou lorsque l’agent Azure Monitor n’est pas accessible.
  • L’agent Azure Monitor ingère les événements Syslog via le socket mentionné précédemment et les filtre en fonction de la combinaison de facilités ou de gravité de la configuration de la règle de collecte de données (DCR) dans /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/. Tout facility ou severity non présent dans la règle DCR est supprimé.
  • L’agent Azure Monitor tente d’analyser les événements conformément aux documents RFC3164 et RFC5424. Il sait également comment analyser les formats de message répertoriés sur ce site web.
  • L’agent Azure Monitor identifie le point de terminaison de destination des événements Syslog à partir de la configuration DCR et tente de charger les événements.

    Notes

    L’agent Azure Monitor utilise la persistance locale par défaut. Tous les événements reçus de rsyslog ou syslog-ng sont mis en file d'attente dans /var/opt/microsoft/azuremonitoragent/events si leur chargement échoue.

Problèmes

Vous risquez de rencontrer les problèmes suivants.

Les données rsyslog ne sont pas chargées en raison d’un problème d’espace disque complet sur l’Agent Azure Monitor pour Linux

Les sections suivantes décrivent le problème.

Symptôme

Les données Syslog ne se chargent pas – Lors de l’inspection des journaux des erreurs dans /var/opt/microsoft/azuremonitoragent/log/mdsd.err, vous voyez des entrées de type Erreur lors de l’insertion de l’élément dans Magasin persistant local... Espace insuffisant sur l’appareil, comme dans l’extrait de code suivant :

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

Cause

L’agent Azure Monitor pour Linux met en mémoire tampon les événements dans /var/opt/microsoft/azuremonitoragent/events avant l’ingestion. Pour une installation par défaut de l’agent Azure Monitor pour Linux, ce répertoire prend environ 650 Mo d’espace disque au moment de l’inactivité. La taille sur le disque augmente lorsque sa charge de journalisation est soutenue. Le répertoire est nettoyé environ toutes les 60 secondes et redescend à environ 650 Mo lorsque la charge redevient inactive.

Confirmer le problème de disque plein

La commande df indique qu’il n’y a pratiquement plus d’espace disponible sur /dev/sda1, comme indiqué dans la sortie suivante. Notez que vous devez examiner l’élément de ligne qui correspond au répertoire du journal (par exemple, /var/log ou /var ou /).

   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

Vous pouvez utiliser la commande du pour inspecter le disque afin de déterminer les fichiers à l’origine de la saturation du disque. Par exemple :

   cd /var/log
   du -h syslog*

6.7G    syslog
18G     syslog.1

Dans certains cas, du peut ne pas signaler de fichiers ou de répertoires volumineux. Il est possible qu’un fichier marqué comme (supprimé) occupe tout l’espace. Ce problème peut se produire quand un processus tente de supprimer un fichier, mais qu’un processus d’un fichier est encore ouvert. Vous pouvez utiliser la commande lsof pour vérifier de tels fichiers. Dans l’exemple suivant, nous voyons que /var/log/syslog est marqué comme supprimé, mais qu’il occupe 3,6 Go d’espace disque. Il n’a pas été supprimé, car un processus avec le PID 1484 a toujours le fichier ouvert.

   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)

La configuration par défaut de rsyslog journalise toutes les installations dans /var/log/

Sur certaines distributions populaires (comme Ubuntu 18.04 LTS), rsyslog est fourni avec un fichier config par défaut (/etc/rsyslog.d/50-default.conf) qui journalise les événements de la quasi-totalité des installations sur le disque à l’emplacement /var/log/syslog. Les événements Syslog de la famille RedHat/CentOS sont stockés sous /var/log/, mais dans un autre fichier : /var/log/messages.

L’agent Azure Monitor ne s’appuie pas sur les événements Syslog journalisés dans /var/log/. Au lieu de cela, il configure le service rsyslog pour qu’il transfère les événements sur un port TCP directement vers le processus de service azuremonitoragent (mdsd).

Correctif : supprimer les facilities à volume élevé de /etc/rsyslog.d/50-default.conf

Si vous envoyez un volume de journal élevé via rsyslog et que votre système est configuré pour journaliser les événements pour ces installations, envisagez de modifier la configuration rsyslog par défaut pour éviter la journalisation et les stocker sous /var/log/. Les événements de cette fonctionnalité sont toujours transférés vers l’agent Azure Monitor, car rsyslog utilise une configuration différente pour le transfert placé dans /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf.

  1. Par exemple, pour supprimer la journalisation des événements local4 dans /var/log/syslog ou /var/log/messages, remplacez cette ligne dans /etc/rsyslog.d/50-default.conf de cet extrait de code :

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

    À cet extrait de code (ajoutez local4.none;) :

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

  2. sudo systemctl restart rsyslog

La mémoire tampon d’événements de l’agent Azure Monitor pour Linux remplit un disque

Si vous observez que le répertoire /var/opt/microsoft/azuremonitor/events augmente sans limites (10 Go ou plus) et que sa taille ne diminue pas, créez un ticket. Pour Résumé, entrez La mémoire tampon d’événements de l’agent Azure Monitor remplit le disque. Pour Type de problème, entrez J’ai besoin d’aide pour configurer la collecte de données à partir d’une machine virtuelle.

Créer un ticket

  1. Ouvrez une règle de collecte de données puis, dans le menu de gauche, sélectionnez Nouvelle demande de support. Vous pouvez également ouvrir le volet Aide et support et sélectionner Créer une demande de support.
  2. Sélectionnez :
    • Type de problème : Technique.
    • Abonnement : Sélectionnez l’abonnement où résident vos machines.
    • Type de service : Règles de collecte de données et Agent Azure Monitor.
    • Votre problème est-il lié à une ressource ? : Oui. Sélectionnez votre machine à l’aide du sélecteur de ressource.
  3. Entrez un Récapitulatif et le Type de problème comme indiqué dans les étapes de résolution des problèmes. Plus les informations sont précises, plus le problème est résolu rapidement.
  4. Sélectionnez Suivant et passez en revue les solutions recommandées pour voir si elles vous sont utiles.
  5. Si ce n’est pas le cas, sélectionnez Suivant et renseignez l’ensemble de détails suivant.
  6. Sélectionnez Suivant, passez en revue les détails finaux, puis sélectionnez Créer.