Résoudre les problèmes liés à l’agent Log Analytics pour Linux

  • Article

Cet article fournit de l’aide pour la résolution des problèmes que vous pouvez rencontrer avec l’agent Log Analytics pour Linux dans Azure Monitor.

Outil de résolution des problèmes Log Analytics

L’outil de résolution des problèmes de l’agent Log Analytics pour Linux est un script conçu pour faciliter la recherche et le diagnostic des problèmes liés à l’agent Log Analytics. Il est inclus automatiquement avec l’agent lors de l’installation. L’exécution de l’outil doit être la première étape du diagnostic d’un problème.

Utiliser l’outil de résolution des problèmes

Pour exécuter l’outil de résolution des problèmes, collez la commande suivante dans une fenêtre de terminal sur une machine où l’agent Log Analytics est installé :

sudo /opt/microsoft/omsagent/bin/troubleshooter

Installation manuelle

L’outil de résolution des problèmes est inclus automatiquement lors de l’installation de l’agent Log Analytics. Si l’installation échoue d’une façon ou d’une autre, vous pouvez également installer l’outil manuellement :

  1. Vérifiez que GDB (GNU Project Debugger) est installé sur la machine, car l’utilitaire de résolution des problèmes s’appuie sur celui-ci.
  2. Copiez le pack de l’utilitaire de résolution des problèmes sur votre ordinateur : wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
  3. Décompressez le pack : tar -xzvf omsagent_tst.tar.gz
  4. Exécutez l’installation manuelle : sudo ./install_tst

Scénarios couverts

L’outil de résolution des problèmes vérifie les scénarios suivants :

  • L’agent est non sain ; la pulsation ne fonctionne pas correctement.
  • L’agent ne démarre pas ou ne peut pas se connecter à Log Analytics.
  • Le Syslog de l’agent ne fonctionne pas.
  • L’agent a une utilisation élevée du processeur ou de la mémoire.
  • L’agent a des problèmes d’installation.
  • Les journaux personnalisés de l’agent ne fonctionnent pas.
  • Les journaux de l’agent ne peuvent pas être collectés.

Pour plus d’informations, consultez la documentation de l’outil de résolution des problèmes sur GitHub.

Notes

Exécutez l’outil collecteur de journaux si vous rencontrez un problème. Le fait d’avoir les journaux dès le départ permettra à notre équipe de support de résoudre plus rapidement votre problème.

Vider et réinstaller l’agent Linux

Une réinstallation propre de l’agent résout la plupart des problèmes. Cette tâche peut être la première suggestion de notre équipe de support technique pour replacer l’agent dans un état non endommagé. L’exécution de l’outil de résolution des problèmes et de l’outil collecteur de journaux ainsi qu’une tentative de réinstallation propre permettent de résoudre plus rapidement les problèmes.

  1. Téléchargez le script de vidage :

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

  2. Exécutez le script de vidage (avec les autorisations sudo) :

    $ sudo sh purge_omsagent.sh

Emplacement des journaux importants et outil collecteur de journaux

Fichier Path
Fichier journal de l’agent Log Analytics pour Linux /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Fichier journal de configuration de l’agent Log Analytics /var/opt/microsoft/omsconfig/omsconfig.log

Nous vous recommandons d’utiliser notre outil collecteur de journaux pour récupérer les journaux d’activité importants à des fins de résolution des problèmes ou avant de soumettre un problème GitHub. Pour plus d’informations sur l’outil et sur son exécution, consultez OMS Linux Agent Log Collector.

Fichiers de configuration importants

Category Emplacement du fichier
syslog /etc/syslog-ng/syslog-ng.conf ou /etc/rsyslog.conf ou /etc/rsyslog.d/95-omsagent.conf
Performances, Nagios, Zabbix, sortie Log Analytics et agent général /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
Configurations supplémentaires /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

Notes

La modification des fichiers de configuration pour les compteurs de performances et Syslog est remplacée si la collection est configurée à partir de la configuration de l’agent dans le portail Azure pour votre espace de travail. Pour désactiver la configuration pour tous les agents, désactivez la collection dans la Gestion des agents hérités. Pour un seul agent, exécutez le script suivant :

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 d’erreur d’installation

Code d'erreur Signification
NOT_DEFINED Les dépendances nécessaires n’étant pas installées, le plug-in auoms auditd ne sera pas installé. Échec de l’installation de auoms. Installez le package auditd.
2 Option non valide fournie au bundle de l’interpréteur de commandes. Exécutez sudo sh ./omsagent-*.universal*.sh --help pour l’utilisation.
3 Aucune option fournie au bundle de l’interpréteur de commandes. Exécutez sudo sh ./omsagent-*.universal*.sh --help pour l’utilisation.
4 Type de package non valide ou paramètres de proxy non valides. Les packages omsagent-rpm.sh ne peuvent être installés que sur des systèmes RPM. Les packages omsagent-deb.sh ne peuvent être installés que sur des systèmes Debian. Nous vous recommandons d’utiliser le programme d’installation universel de la dernière version. Par ailleurs, lisez ces informations pour vérifier vos paramètres de proxy.
5 Le bundle du shell doit être exécuté en tant qu’utilisateur root ou une erreur 403 a été retournée pendant l’intégration. Exécutez votre commande en utilisant sudo.
6 Architecture de package non valide ou une erreur 200 a été retournée pendant l’intégration. Les packages omsagent-*x64.sh ne peuvent être installés que sur des systèmes 64 bits. Les packages omsagent-*x86.sh ne peuvent être installés que sur des systèmes 32 bits. Téléchargez le package approprié pour votre architecture à partir de la dernière version.
17 Échec de l’installation du package OMS. Examinez le résultat de la commande pour déterminer l’échec de root.
18 Échec de l’installation du package OMSConfig. Examinez le résultat de la commande pour déterminer l’échec de root.
19 Échec de l’installation du package OMI. Examinez le résultat de la commande pour déterminer l’échec de root.
20 Échec de l’installation du package SCX. Examinez le résultat de la commande pour déterminer l’échec de root.
21 Échec de l’installation des kits Provider. Examinez le résultat de la commande pour déterminer l’échec de root.
22 Échec de l’installation du package fourni. Examinez le résultat de la commande pour déterminer l’échec de root.
23 Package SCX ou OMI déjà installé. Utilisez --upgrade au lieu de --install pour installer le bundle de l’interpréteur de commandes.
30 Erreur d’application interne. Créez un problème GitHub en indiquant les détails de la sortie.
55 Version d’openssl non prise en charge ou connexion impossible à Azure Monitor ou dpkg est verrouillé ou programme curl manquant.
61 Bibliothèque de ctypes Python manquante. Installez la bibliothèque ou le package de ctypes Python (python-ctypes).
62 Programme tar manquant. Installez tar.
63 Programme sed manquant. Installez sed.
64 Programme curl manquant. Installez curl.
65 Programme gpg manquant. Installez gpg.

Codes d’erreur d’intégration

Code d'erreur Signification
2 Option non valide fournie au script omsadmin. Exécutez sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h pour l’utilisation.
3 Configuration non valide fournie au script omsadmin. Exécutez sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h pour l’utilisation.
4 Proxy non valide fourni au script omsadmin. Vérifiez le proxy et consultez notre documentation sur l’utilisation d’un proxy HTTP.
5 Erreur HTTP 403 provenant d’Azure Monitor. Consultez la sortie complète du script omsadmin pour plus d’informations.
6 Erreur non HTTP 200 provenant d’Azure Monitor. Consultez la sortie complète du script omsadmin pour plus d’informations.
7 Impossible de se connecter à Azure Monitor. Consultez la sortie complète du script omsadmin pour plus d’informations.
8 Erreur d’intégration de l’espace de travail Log Analytics. Consultez la sortie complète du script omsadmin pour plus d’informations.
30 Erreur de script interne. Créez un problème GitHub en indiquant les détails de la sortie.
31 Erreur de génération d’ID d’agent. Créez un problème GitHub en indiquant les détails de la sortie.
32 Erreur de génération de certificats. Consultez la sortie complète du script omsadmin pour plus d’informations.
33 Erreur de génération d’une métaconfiguration pour omsconfig. Créez un problème GitHub en indiquant les détails de la sortie.
34 Script de génération de métaconfiguration absent. Recommencez l’intégration avec sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key>.

Activer l’enregistrement du débogage

Débogage du plug-in de sortie OMS

FluentD prend en charge des niveaux de journalisation spécifiques au plug-in, ce qui vous permet de spécifier différents niveaux de journal pour les entrées et les sorties. Pour spécifier un autre niveau du journal pour une sortie OMS, modifiez la configuration générale de l’agent à l’emplacement /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Dans le plug-in de sortie OMS, avant la fin du fichier de configuration, changez la propriété log_level de info en 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>

La journalisation du débogage vous permet de voir les chargements par lot sur Azure Monitor, répartis par type, par nombre d’éléments de données et par temps nécessaire à l’envoi :

Voici un exemple de journal activé pour le débogage :

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

Sortie détaillée.

Au lieu d’utiliser le plug-in de sortie OMS, vous pouvez envoyer les éléments de données directement sur stdout, qui est visible dans le fichier journal de l’agent Log Analytics pour Linux.

Dans le fichier de configuration générale de l’agent Log Analytics /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf, placez en commentaire le plug-in de sortie OMS en ajoutant un # au début de chaque ligne :

#<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>

Sous le plug-in de sortie, décommentez la section suivante en supprimant le # au début de chaque ligne :

<match **>
  type stdout
</match>

Problème : Impossible de se connecter via le proxy à Azure Monitor

Causes probables

  • Le proxy spécifié lors de l’intégration est incorrect.
  • Les points de terminaison des services Azure Monitor et Azure Automation ne figurent pas dans la liste approuvée de votre centre de données.

Résolution

  1. Réintégrez Azure Monitor avec l’agent Log Analytics pour Linux à l’aide de la commande suivante avec l’option -v activée. Cela autorise une sortie détaillée de l’agent qui se connecte via le proxy à Azure Monitor : /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

  2. Pour vérifier que vous avez correctement configuré l’agent de manière à communiquer via un serveur proxy, consultez la section Mettre à jour les paramètres du proxy.

  3. Vérifiez que les points de terminaison décrits dans la liste Configuration requise du pare-feu réseau Azure Monitor sont correctement ajoutés à une liste d’autorisation. Si vous utilisez Azure Automation, un lien d’accès aux étapes de configuration du réseau est également disponible ci-dessus.

Problème : vous voyez une erreur 403 lorsque vous tentez d’effectuer l’intégration

Causes probables

  • La date et l’heure sont incorrectes sur le serveur Linux.
  • L’ID d’espace de travail et la clé d’espace de travail ne sont pas corrects.

Résolution

  1. Vérifiez l’heure sur votre serveur Linux avec la commande date. Si l’heure varie de +/-15 minutes par rapport à l’heure en cours, l’intégration échoue. Pour corriger cette situation, mettez à jour de la date et/ou le fuseau horaire de votre serveur Linux.
  2. Vérifiez que vous avez installé la dernière version de l’agent Log Analytics pour Linux. Celle-ci vous avertit si le décalage horaire est à l’origine de l’échec d’intégration.
  3. Relancez l’intégration en utilisant l’ID d’espace de travail et la clé d’espace de travail corrects en suivant les instructions d’installation fournies précédemment dans cet article.

Problème : vous voyez une erreur 500 et 404 dans le fichier journal juste après l’intégration

C’est un problème connu qui se produit lors du premier chargement de données Linux dans un espace de travail Log Analytics. Ce problème n’affecte pas les données envoyées ni l’expérience du service.

Problème : Vous voyez que l’omiagent utilise 100 % du processeur

Causes probables

Une régression dans le package nss-pem v1.0.3-5.el7 a provoqué un grave problème de performances. Ce problème survient fréquemment dans les distributions Redhat/CentOS 7.x. Pour en savoir plus sur ce problème, consultez 1667121 - Régression des performances dans libcurl.

Les bogues relatifs aux performances ne se produisent pas tout le temps et sont difficiles à reproduire. Si vous rencontrez ce genre de problèmes avec omiagent, utilisez le script omiHighCPUDiagnostics.sh, qui va collecter les traces d’omiagent quand il dépasse un certain seuil.

  1. Téléchargez le script :
    wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

  2. Exécutez les diagnostics pendant 24 heures avec un seuil de processeur de 30 % :
    bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

  3. La pile d’appels est vidée dans le fichier omiagent_trace. Si vous remarquez de nombreux appels de fonction curl et NSS, suivez ces étapes de résolution.

Résolution

  1. Mettez à niveau le package nss-pem vers la version v1.0.3-5.el7_6.1 :
    sudo yum upgrade nss-pem

  2. Si nss-pem n’est pas disponible pour la mise à niveau, ce qui concerne principalement CentOS, rétrogradez curl à la version 7.29.0-46. Si vous exécutez par erreur « yum update », curl sera mis à niveau vers 7.29.0-51 et le problème se produira à nouveau :
    sudo yum downgrade curl libcurl

  3. Redémarrez OMI :
    sudo scxadmin -restart

Problème : Vous ne voyez pas les messages Syslog transférés

Causes probables

  • La configuration appliquée au serveur Linux n’autorise pas la collecte des fonctionnalités ou des niveaux de journal envoyés.
  • Syslog n’est pas transmis correctement au serveur Linux.
  • Le nombre de messages transmis par seconde est trop élevé pour être géré avec la configuration de base de l’agent Log Analytics pour Linux.

Résolution

  • Vérifiez que la configuration de l’espace de travail Log Analytics pour Syslog possède toutes les fonctionnalités nécessaires et les niveaux corrects du journal d’activité. Consultez Configurer la collecte Syslog dans le portail Azure.
  • Vérifiez que les démons de messagerie Syslog natifs (rsyslog, syslog-ng) peuvent recevoir les messages transférés
  • Vérifiez les paramètres de pare-feu sur le serveur Syslog pour être sûr que les messages ne sont pas bloqués.
  • Simulez un message Syslog pour Log Analytics en utilisant la commande logger :
    logger -p local0.err "This is my test message"

Problème : Vous recevez une erreur Errno indiquant qu’une adresse est déjà en cours d’utilisation dans le fichier journal omsagent

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

Causes probables

Cette erreur indique que l’extension de diagnostic Linux (LAD, Linux Diagnostic Extension) est installée côte à côté avec l’extension de machine virtuelle Linux Log Analytics. Elle utilise le même port qu’omsagent pour la collecte de données Syslog.

Résolution

  1. En tant qu’utilisateur root, exécutez les commandes suivantes. Notez que 25224 est un exemple et que vous êtes susceptible de voir dans votre environnement un autre numéro de port utilisé par LAD.

    /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

    Vous devez ensuite modifier le fichier config rsyslogd ou syslog_ng correct et changer la configuration liée à LAD pour écrire sur le port 25229.

  2. Si la machine virtuelle exécute rsyslogd, le fichier à modifier est /etc/rsyslog.d/95-omsagent.conf (s’il existe ; sinon c’est /etc/rsyslog). Si la machine virtuelle exécute syslog_ng, le fichier à modifier est /etc/syslog-ng/syslog-ng.conf.

  3. Redémarrez omsagent (sudo /opt/microsoft/omsagent/bin/service_control restart).

  4. Redémarrez le service Syslog.

Problème : Vous ne parvenez pas à désinstaller omsagent en utilisant l’option de vidage

Causes probables

  • L’extension de diagnostic Linux est installée.
  • L’extension de diagnostic Linux a été installée et désinstallée, mais vous voyez toujours une erreur indiquant qu’omsagent est utilisé par mdsd et qu’il ne peut pas être supprimé.

Résolution

  1. Désinstallez l’extension de diagnostic Linux.
  2. Supprimez les fichiers de l’extension de diagnostic Linux de la machine s’ils sont présents à l’emplacement suivant : /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ et /var/opt/microsoft/omsagent/LAD/.

Problème : Vous ne pouvez pas voir de données Nagios

Causes probables

  • L’utilisateur omsagent n’a pas les autorisations nécessaires pour lire le fichier journal Nagios.
  • La source et le filtre Nagios n’ont pas été décommentés dans le fichier omsagent.conf.

Résolution

  1. Ajoutez l’utilisateur omsagent pour lire à partir du fichier Nagios en suivant ces instructions.

  2. Dans le fichier de configuration générale de l’agent Log Analytics pour Linux situé à l’emplacement /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf, vérifiez que la source et le filtre Nagios sont tous deux exempts de marques de commentaire.

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

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

Problème : Vous ne voyez pas de données Linux

Causes probables

  • Échec de l’intégration à Azure Monitor.
  • La connexion à Azure Monitor est bloquée.
  • La machine virtuelle a été redémarrée.
  • Le package OMI a été mis à niveau manuellement vers une version plus récente que ce qu’a installé le package de l’agent Log Analytics pour Linux.
  • OMI est bloqué, ce qui bloque l’agent OMS.
  • La ressource DSC journalise une erreur classe introuvable dans le fichier journal omsconfig.log.
  • Les données de l’agent Log Analytics sont sauvegardées.
  • DSC consigne le message La configuration actuelle n’existe pas. Exécutez la commande Start-DscConfiguration avec le paramètre -Path pour commencer par spécifier un fichier config et créer une configuration actuelle. dans le fichier journal omsconfig.log, mais aucun message de journal n’existe concernant les opérations PerformRequiredConfigurationChecks.

Résolution

  1. Installez toutes les dépendances, comme le package auditd.

  2. Vérifiez si l’intégration à Azure Monitor a réussi en vous assurant que le fichier suivant existe : /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Si ce n’était pas le cas, relancez l’intégration en utilisant les instructions de la ligne de commande omsadmin.sh.

  3. Si vous utilisez un proxy, consultez les étapes précédentes de résolution des problèmes du proxy.

  4. Dans certains systèmes de distribution Azure, le démon de serveur OMI omid ne démarre pas après le redémarrage de la machine virtuelle. Si c’est le cas, vous ne verrez pas les données liées à la solution Audit, ChangeTracking ou UpdateManagement. La solution de contournement consiste à démarrer manuellement le serveur OMI en exécutant sudo /opt/omi/bin/service_control restart.

  5. Une fois le package OMI mis à niveau manuellement vers une version plus récente, il doit être redémarré manuellement pour que l’agent Log Analytics continue à fonctionner correctement. Cette étape est nécessaire pour certaines distributions où le serveur OMI ne démarre pas automatiquement après sa mise à niveau. Exécutez sudo /opt/omi/bin/service_control restart pour redémarrer OMI.

    Dans certaines situations, OMI peut être bloqué. L’agent OMS peut entrer dans un état bloqué en attente d’OMI, ce qui bloque la collecte de toutes les données. Le processus de l’agent OMS sera en cours d’exécution, mais il n’y aura aucune activité, comme le montre l’absence de nouvelles lignes de journal (par exemple les pulsations envoyées) dans omsagent.log. Redémarrez OMI avec sudo /opt/omi/bin/service_control restart pour récupérer l’agent.

  6. Si vous voyez une erreur classe introuvable pour les ressources DSC dans omsconfig.log, exécutez sudo /opt/omi/bin/service_control restart.

  7. Dans certains cas, quand l’agent Log Analytics pour Linux ne peut pas échanger avec Azure Monitor, les données de l’agent sont sauvegardées jusqu’à la taille maximale de la mémoire tampon de 50 Mo. Il est nécessaire de redémarrer l’agent en exécutant la commande suivante : /opt/microsoft/omsagent/bin/service_control restart.

    Notes

    Ce problème est résolu dans l’agent version 1.1.0-28 ou ultérieure.

    • Si le fichier journal omsconfig.log n’indique pas que des opérations PerformRequiredConfigurationChecks s’exécutent régulièrement sur le système, il peut y avoir un problème avec le service/travail cron. Vérifiez que le travail cron existe sous /etc/cron.d/OMSConsistencyInvoker. Si nécessaire, exécutez les commandes suivantes pour créer le travail cron :

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

    • En outre, assurez-vous que le service cron est en cours d’exécution. Vous pouvez utiliser service cron status avec Debian, Ubuntu et SUSE, ou service crond status avec RHEL, CentOS et Oracle Linux pour vérifier l’état de ce service. Si le service n’existe pas, vous pouvez installer les fichiers binaires et démarrer le service en utilisant les instructions suivantes :

      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

Problème : Quand vous configurez la collecte à partir du portail pour les compteurs de performances Syslog ou Linux, les paramètres ne sont pas appliqués

Causes probables

  • L’agent Log Analytics pour Linux n’a pas récupéré la configuration la plus récente.
  • Les paramètres modifiés dans le portail n’ont pas été appliqués.

Résolution

Contexte :omsconfig est l’agent de configuration de l’agent Log Analytics pour Linux qui cherche la nouvelle configuration côté portail toutes les cinq minutes. Cette configuration est ensuite appliquée aux fichiers de configuration de l’agent Log Analytics pour Linux situés à l’emplacement /etc/opt/microsoft/omsagent/conf/omsagent.conf.

Dans certains cas, l’agent de configuration de l’agent Log Analytics pour Linux n’est pas en mesure de communiquer avec le service de configuration du portail. Ce scénario fait que la configuration la plus récente n’est pas appliquée.

  1. Vérifiez que l’agent omsconfig est installé en exécutant dpkg --list omsconfig ou rpm -qi omsconfig. S’il n’est pas installé, réinstallez la dernière version de l’agent Log Analytics pour Linux.

  2. Vérifiez que l’agent omsconfig peut communiquer avec Azure Monitor en exécutant la commande suivante : sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Cette commande retourne la configuration que l’agent reçoit du service, y compris les paramètres Syslog, les compteurs de performances Linux et les journaux personnalisés. Si cette commande échoue, exécutez la commande suivante : sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Cette commande force l’agent omsconfig à parler à Azure Monitor pour récupérer la configuration la plus récente.

Problème : Vous ne pouvez pas voir de données de journal personnalisé

Causes probables

  • Échec de l’intégration à Azure Monitor.
  • Le paramètre Appliquer la configuration suivante à mes serveurs Linux n’a pas été sélectionné.
  • omsconfig n’a pas récupéré la dernière configuration du journal personnalisé auprès du service.
  • L’utilisateur omsagent de l’agent Log Analytics pour Linux ne parvient pas à accéder au journal personnalisé parce qu’il n’a pas les autorisations ou qu’il ne le trouve pas. Les erreurs suivantes peuvent s’afficher :
    • [DATETIME] [warn]: file not found. Continuing without tailing it.
    • [DATETIME] [error]: file not accessible by omsagent.
  • Problème connu lié à une condition de concurrence corrigé dans la version 1.1.0-217 de l’agent Log Analytics pour Linux.

Résolution

  1. Vérifiez si l’intégration à Azure Monitor a réussi en vous assurant que le fichier suivant existe : /etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf. Si ce n’est pas le cas, effectuez l’une des deux opérations suivantes :

    1. Relancez l’intégration en utilisant les instructions de la ligne de commande omsadmin.sh.
    2. Sous Paramètres avancés dans le portail Azure, vérifiez que le paramètre Appliquer la configuration suivante à mes serveurs Linux est activé.

  2. Vérifiez que l’agent omsconfig peut communiquer avec Azure Monitor en exécutant la commande suivante : sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'. Cette commande retourne la configuration que l’agent reçoit du service, y compris les paramètres Syslog, les compteurs de performances Linux et les journaux personnalisés. Si cette commande échoue, exécutez la commande suivante : sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'. Cette commande force l’agent omsconfig à dialoguer avec Azure Monitor pour récupérer la configuration la plus récente.

Contexte : au lieu que l’agent Log Analytics pour Linux opère en tant qu’utilisateur privilégié - root, l’agent opère en tant qu’utilisateur omsagent. Dans la plupart des cas, une autorisation explicite doit être accordée à cet utilisateur pour la lecture de certains fichiers. Pour accorder l’autorisation à l’utilisateur omsagent, exécutez les commandes suivantes :

  1. Ajoutez l’utilisateur omsagent au groupe spécifique : sudo usermod -a -G <GROUPNAME> <USERNAME>.
  2. Accordez l’accès en lecture universel au fichier requis : sudo chmod -R ugo+rx <FILE DIRECTORY>

Il existe un problème connu lié à une condition de concurrence affectant les versions de l’agent Log Analytics pour Linux antérieures à 1.1.0-217. Après avoir effectué la mise à jour vers le dernier agent, exécutez la commande suivante pour obtenir la dernière version du plug-in de sortie : sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf.

Problème : Vous tentez d’effectuer une réintégration dans un nouvel espace de travail

Quand vous tentez de réintégrer un agent dans un nouvel espace de travail, la configuration de l’agent Log Analytics doit être nettoyée avant la réintégration. Pour nettoyer l’ancienne configuration de l’agent, exécutez le bundle du shell avec --purge :

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

ou

sudo sh ./onboard_agent.sh --purge

Vous pouvez continuer la réintégration après avoir utilisé l’option --purge.

Problème : L’extension de l’agent Log Analytics dans le portail Azure est marquée avec un état d’échec : Échec du provisionnement

Causes probables

  • L’agent Log Analytics a été supprimé du système d’exploitation.
  • Le service de l’agent Log Analytics est arrêté, désactivé ou n’est pas configuré.

Résolution

  1. Supprimez l’extension du portail Azure.
  2. Installez l’agent en suivant les instructions.
  3. Redémarrez l’agent en exécutant la commande suivante :
    sudo /opt/microsoft/omsagent/bin/service_control restart.
  4. Attendez quelques minutes jusqu’à ce que l’état de provisionnement passe à Provisionnement réussi.

Problème : Mise à jour de l’agent Log Analytics à la demande

Causes probables

Les packages de l’agent Log Analytics sur l’hôte sont obsolètes.

Résolution

  1. Recherchez la dernière version dans cette page GitHub.

  2. Télécharger le script d’installation (1.4.2-124 est un exemple de version) :

    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. Mettez à niveau les packages en exécutant sudo sh ./omsagent-*.universal.x64.sh --upgrade.

Problème : L’installation échoue et indique que Python2 ne peut pas prendre en charge les ctypes, même si Python3 est utilisé

Causes probables

Pour ce problème connu, si la langue de la machine virtuelle n’est pas l’anglais, un contrôle échoue lors de la vérification de la version de Python utilisée. Ce problème fait que l’agent part toujours du principe que Python2 est utilisé, et un échec se produit si Python2 est absent.

Résolution

Modifiez la langue de l’environnement de la machine virtuelle sur l’anglais :

export LANG=en_US.UTF-8