Instructions de résolution des problèmes liés à l’agent Azure Monitor sur des machines virtuelles Linux et des groupes identiques

Article
11/14/2024

Vue d’ensemble de l’agent Azure Monitor

Avant de continuer, vous devez vous familiariser avec l’agent Azure Monitor et les règles de collecte de données.

Terminologie

Nom	Acronyme	Description
Agent Azure Monitor	AMA	Nouvel agent Azure Monitor
Règles de collecte des données	DCR	Règles permettant de configurer la collecte de données par l’agent, c.-à-d. quels éléments collecter, où les envoyer, etc.
Azure Monitor Configuration Service	AMCS	Service régional hébergé dans Azure qui contrôle la collecte de données pour cet agent et d’autres parties d’Azure Monitor. L’agent appelle ce service pour récupérer (fetch) les règles DCR.
Point de terminaison de journaux	--	Point de terminaison pour l’envoi de données à des espaces de travail Log Analytics
Point de terminaison de métriques	--	Point de terminaison pour l’envoi de données à des bases de données Métriques Azure Monitor
Instance Metadata Service et Hybrid Instance Metadata Service	IMDS et HIMDS	Services hébergés dans Azure qui fournissent des informations sur les machines virtuelles en cours d’exécution, les groupes identiques (via IMDS) et les serveurs avec Arc (via HIMDS)
Espace de travail Log Analytics	LAW	Destination dans Azure Monitor où vous pouvez envoyer les journaux collectés par l’agent
Métriques personnalisées	--	Destination dans Azure Monitor où vous pouvez envoyer les métriques d’invité collectées par l’agent

Étapes de dépannage de base

Suivez les étapes ci-dessous pour résoudre les problèmes liés à la dernière version de l’agent Azure Monitor s’exécutant sur votre machine virtuelle Linux :

Examinez attentivement les prérequis ici.
Vérifiez que l’extension qui installe les fichiers binaires de l’agent sur votre ordinateur est correctement installée et provisionnée :
1. Ouvrez le portail Azure > sélectionnez votre machine virtuelle > ouvrez Paramètres : Extensions + applications dans le volet de gauche > « AzureMonitorLinuxAgent » doit apparaître avec l’état « Provisionnement réussi ».
2. Si l’extension n’est pas listée, vérifiez si la machine peut atteindre Azure et recherchez l’extension à installer en utilisant la commande ci-dessous :
```
az vm extension image list-versions --location <machine-region> --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor
```
3. Attendez 10 à 15 minutes, car l’extension peut être dans un état de transition. Si elle n’apparaît toujours pas comme ci-dessus, désinstallez et réinstallez l’extension.
4. Recherchez la présence d’erreurs dans les journaux d’extension situés à l’emplacement /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ sur votre ordinateur.
Vérifiez que l’agent est en cours d’exécution :
1. Vérifiez si l’agent émet des journaux de pulsations dans l’espace de travail Log Analytics en utilisant la requête ci-dessous. Ignorez cette étape si « Métriques personnalisées » est la seule destination dans la règle DCR :
```
Heartbeat | where Category == "Azure Monitor Agent" and Computer == "<computer-name>" | take 10
```
2. Vérifiez si le service de l’agent est en cours d’exécution.
```
systemctl status azuremonitoragent
```
3. Recherchez la présence d’erreurs dans les principaux journaux d’agent à l’emplacement /var/opt/microsoft/azuremonitoragent/log/mdsd.* sur votre ordinateur.
Vérifiez que la règle DCR existe et qu’elle est associée à la machine virtuelle :
1. Si vous utilisez l’espace de travail Log Analytics comme destination, vérifiez que la règle DCR existe dans la même région physique que l’espace de travail Log Analytics.
2. Ouvrez le portail Azure > sélectionnez votre règle de collecte de données > ouvrez Configuration : Ressources dans le volet de gauche > vous devriez voir la machine virtuelle listée ici.
3. Si ce n’est pas le cas, cliquez sur Ajouter et sélectionnez votre machine virtuelle dans le sélecteur de ressources. Recommencez sur toutes les règles DCR.
Vérifiez que l’agent a pu télécharger la ou les règles DCR associées à partir du service AMCS :
1. Vérifiez si vous voyez la dernière règle DCR téléchargée à l’emplacement /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/.

Problèmes de collecte de Syslog

Pour plus d’informations sur la résolution des problèmes syslog avec l’agent Azure Monitor , cliquez ici.

Le fichier de qualité de service (QoS) /var/opt/microsoft/azuremonitoragent/log/mdsd.qos fournit des agrégations au format CSV de 15 minutes des événements traités et contient les informations sur le nombre d’événements syslog traités dans le délai d’exécution donné. Ce fichier est utile pour le suivi des suppressions d’ingestion d’événements Syslog.

Par exemple, le fragment ci-dessous montre que dans les 15 minutes avant 2022-02-28T19:55:23.5432920Z, l’agent a reçu 77 événements syslog avec daemon comme facility et info comme niveau, et a envoyé 77 de ces événements à la tâche de chargement. En outre, la tâche de chargement de l’agent a reçu 77 messages daemon.info et a chargé ces 77 messages.
```
#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
```

Étapes de dépannage

Pour commencer, passez en revue les étapes de dépannage génériques d’AMA Linux. Si l’agent émet des pulsations, passez à l’étape 2.
La configuration analysée est stockée à l’emplacement /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/. Vérifiez que la collection Syslog est définie et que les destinations des journaux sont identiques à celles construites dans l’interface utilisateur ou le fichier JSON de la règle DCR.
1. Si oui, passez à l’étape 3. Si ce n’est pas le cas, le problème réside dans le workflow de configuration.
2. Investiguez les fichiers mdsd.err,mdsd.warn et mdsd.info sous /var/opt/microsoft/azuremonitoragent/log à la recherche d’éventuelles erreurs de configuration.
Validez la disposition du workflow de collecte Syslog pour vous assurer que tous les éléments nécessaires sont en place et accessibles :
1. Pour les utilisateurs de rsyslog, vérifiez que le fichier /etc/rsyslog.d/10-azuremonitoragent.conf est présent, qu’il n’est pas vide et qu’il est accessible par le démon rsyslog (utilisateur syslog).
  1. Vérifiez votre configuration rsyslog sur /etc/rsyslog.conf et /etc/rsyslog.d/* pour vérifier si vous avez des entrées liées à un ensemble de règles non défini par défaut, car les messages de ces entrées ne seront pas transférés à l’agent Azure Monitor. Par exemple, les messages provenant d’une entrée configurée avec un ensemble de règles non défini par défaut comme input(type="imtcp" port="514" ruleset="myruleset") ne seront pas transmis.
2. Pour les utilisateurs de syslog-ng, vérifiez que le fichier /etc/syslog-ng/conf.d/azuremonitoragent.conf est présent, qu’il n’est pas vide et qu’il est accessible par le démon syslog-ng (utilisateur syslog).
3. Vérifiez que le fichier /run/azuremonitoragent/default_syslog.socket existe et qu’il est accessible par rsyslog ou syslog-ng respectivement.
4. Vérifiez que la file d’attente du démon syslog ne déborde pas, ce qui entraîne l’échec du chargement. Pour cela, reportez-vous aux instructions fournies dans Données rsyslog non chargées en raison d’un problème d’espace disque complet sur AMA Linux Agent.

Pour déboguer davantage l’ingestion d’événements syslog, vous pouvez ajouter l’indicateur de trace -T 0x2002 à la fin de MDSD_OPTIONS dans le fichier /etc/default/azuremonitoragent, puis redémarrer l’agent :

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"

Une fois le problème reproduit avec l’indicateur de trace activé, vous trouverez plus d’informations de débogage dans /var/opt/microsoft/azuremonitoragent/log/mdsd.info. Inspectez le fichier pour rechercher la cause possible du problème de collecte syslog, notamment des erreurs d’analyse, de traitement, de configuration ou de téléchargement.

Avertissement

Veillez à supprimer le paramètre d’indicateur de trace -T 0x2002 après la session de débogage, car il génère de nombreuses instructions de trace qui peuvent remplir le disque plus rapidement ou rendre l’analyse visuelle du fichier journal difficile.

Résolution des problèmes sur un serveur avec Arc

Si, après avoir vérifié les étapes de dépannage de base, vous ne voyez pas l’agent Azure Monitor qui émet des journaux ou ne trouvez pas d’erreurs « Échec de l’obtention du jeton MSI à partir du point de terminaison IMDS » dans le fichier journal /var/opt/microsoft/azuremonitoragent/log/mdsd.err, il est probable que l’utilisateur syslog n’est pas membre du groupe himds. Ajoutez un utilisateur syslog au groupe d’utilisateurs himds si l’utilisateur n’est pas membre de ce groupe. Créez l’utilisateur syslog et le groupe syslog, si nécessaire, et assurez-vous que l’utilisateur fait partie de ce groupe. Pour plus d’informations vérifiez les exigences d’authentification de serveur avec Azure Arc ici.

Partager via