Surveiller et dépanner les agents d’ingestion Azure Operator Insights
Pour obtenir une vue d’ensemble des agents d’ingestion, consultez la section Vue d’ensemble de l’agent d’ingestion.
Si vous remarquez des problèmes de collecte de données à partir de vos agents d’ingestion, utilisez les informations de cette section pour résoudre les problèmes courants ou créer un package de diagnostics. Vous pouvez charger le package de diagnostics pour prendre en charge les tickets que vous créez dans le portail Azure.
L’agent d’ingestion est un package logiciel. Les diagnostics sont donc limités au fonctionnement de l’application. Nous ne fournissons pas de système d’exploitation ou de surveillance des ressources. Vous êtes encouragé à utiliser des outils standard tels que snmpd, prometheus node exporter ou d’autres outils pour envoyer des données, des journaux et des métriques au niveau du système d’exploitation à vos propres systèmes de surveillance. Surveiller les machines virtuelles avec Azure Monitor décrit les outils que vous pouvez utiliser si vos agents d’ingestion s’exécutent sur des machines virtuelles Azure.
L’agent écrit des journaux et des métriques dans des fichiers sous /var/log/az-aoi-ingestion/. Si l’agent ne parvient pas à démarrer pour une raison quelconque, par exemple, une configuration incorrecte, le fichier stdout.log contient des journaux lisibles par l’homme expliquant le problème.
Les métriques sont signalées sous un formulaire simple convivial.
Prérequis
- Pour la plupart de ces techniques de dépannage, vous avez besoin d’une connexion SSH à la machine virtuelle exécutant l’agent.
Diagnostics de l’agent d’ingestion
Pour collecter un package de diagnostics, connectez-vous en SSH à la machine virtuelle et exécutez la commande /usr/bin/microsoft/az-aoi-ingestion-gather-diags
. Cette commande génère un fichier zip horodaté dans le répertoire actif que vous pouvez copier à partir du système.
Si vous avez configuré une collection de journaux via l’agent Azure Monitor, vous pouvez afficher les journaux d’agent d’ingestion dans la vue du portail de votre espace de travail Log Analytics et il est possible que vous n’ayez pas besoin de collecter un package de diagnostics pour déboguer vos problèmes.
Remarque
Le Support Microsoft peut demander des packages de diagnostic lors de l’examen d’un problème. Les packages de diagnostic ne contiennent aucune donnée client ni la valeur des informations d’identification.
Problèmes communs à toutes les sources
Les problèmes se répartissent généralement en quatre catégories.
- Une configuration incorrecte de l’agent, ce qui empêche le démarrage de l’agent.
- Problème lié à la réception de données à partir de la source, généralement une mauvaise configuration ou la connectivité réseau.
- Un problème lié au chargement de fichiers dans le compte de stockage d’entrée du produit de données, généralement la connectivité réseau.
- Un problème avec la machine virtuelle sur laquelle l’agent est en cours d’exécution.
L’agent ne parvient pas à démarrer
Symptômes : sudo systemctl status az-aoi-ingestion
indique que le service est en état d’échec.
- Veiller à ce que le service soit en cours d’exécution.
sudo systemctl start az-aoi-ingestion
- Examinez le fichier /var/log/az-aoi-ingestion/stdout.log et recherchez les erreurs signalées. Corrigez les problèmes liés au fichier de configuration et redémarrez l’agent.
Aucune donnée affichée dans Azure Operator Insights
Symptômes : aucune donnée ne s’affiche dans Azure Data Explorer.
- Vérifiez la connectivité réseau et la configuration du pare-feu entre la machine virtuelle de l’agent d’ingestion et le compte de stockage d’entrée du produit de données.
- Vérifiez les journaux de l’agent d’ingestion pour connaître les erreurs de chargement vers Azure. Si les journaux pointent vers des problèmes d’authentification, vérifiez que la configuration de l’agent a les paramètres de récepteur et l’authentification appropriés pour votre produit de données. Ensuite, redémarrez l’agent.
- Vérifiez que l’agent d’ingestion reçoit des données de sa source. Vérifiez la connectivité réseau et la configuration du pare-feu entre votre réseau et l’agent d’ingestion.
Problèmes liés à la source MCC EDR
Cette section traite des problèmes spécifiques à la source MCC EDR.
Vous pouvez également utiliser les diagnostics fournis par les MCC, ou par Azure Operator Insights lui-même dans Azure Monitor, pour vous aider à identifier et à déboguer les problèmes d’ingestion.
MCC ne peut pas se connecter
Symptômes : MCC signale des alarmes sur l’indisponibilité des MSF.
- Vérifiez que l’agent est en cours d’exécution.
- Vérifiez que MCC est configuré avec l’adresse IP et le port appropriés.
- Vérifiez les journaux de l’agent et vérifiez s’il signale des connexions. Si ce n’est pas le cas, vérifiez la connectivité réseau à la machine virtuelle de l’agent et vérifiez que les pare-feu ne bloquent pas le trafic vers le port 36001.
- Collectez une capture de paquets pour voir où la connexion échoue.
Aucune réponse EDR affichée dans Azure Operator Insights
Symptômes : aucune donnée ne s’affiche dans Azure Data Explorer.
- Vérifiez que le MCC est sain et que les agents d’ingestion sont en cours d’exécution.
- Vérifiez les journaux de l’agent d’ingestion dans le package de diagnostics pour les erreurs de chargement sur Azure. Si les journaux pointent vers une chaîne de connexion non valide ou des problèmes de connectivité, corrigez la configuration, la chaîne de connexion ou le jeton SAP, puis redémarrez l’agent.
- Vérifiez la connectivité réseau et la configuration du pare-feu sur le compte de stockage.
Données manquantes ou incomplètes
Symptômes : Azure Monitor affiche un taux EDR entrant inférieur dans ADX que prévu.
- Vérifiez que l'agent s'exécute sur toutes les VMs et ne signale pas d'erreurs dans les journaux du package de diagnostics.
- Vérifiez que les machines virtuelles de l’agent ne sont pas envoyées plus que la charge évaluée.
- Vérifiez les métriques de l’agent dans le package de diagnostics pour les octets supprimés/les EDR supprimés. Si les métriques n’affichent aucune donnée supprimée, MCC n’envoie pas les données à l’agent. Vérifiez les métriques « octets reçus » pour voir la quantité de données reçues de MCC.
- Vérifiez que la machine virtuelle de l’agent n’est pas surchargée, pour surveiller l’utilisation du processeur et de la mémoire. En particulier, assurez-vous qu’aucun autre processus ne prend des ressources à partir de la machine virtuelle.
Problèmes liés à la source d’extraction SFTP
Cette section traite des problèmes spécifiques à la source d’extraction SFTP.
Vous pouvez également utiliser les diagnostics fournis par Azure Operator Insights lui-même dans Azure Monitor pour identifier et déboguer les problèmes d’ingestion.
L’agent ne peut pas se connecter au serveur SFTP
Symptôme : Aucun fichier n’est chargé dans Azure Operator Insights. Le fichier journal de l’agent, /var/log/az-aoi-ingestion/stdout.log, contient des erreurs concernant la connexion du serveur SFTP.
- Vérifiez que l’utilisateur et les informations d’identification SFTP utilisés par l’agent sont valides pour le serveur SFTP.
- Vérifiez la connectivité réseau et la configuration du pare-feu entre l’agent et le serveur SFTP. Par défaut, le serveur SFTP doit avoir le port 22 ouvert pour accepter les connexions SFTP.
- Vérifiez que le fichier
known_hosts
sur la machine virtuelle de l’agent contient une clé SSH publique valide pour le serveur SFTP :- Sur la machine virtuelle de l’agent, exécutez
ssh-keygen -l -F *<sftp-server-IP-or-hostname>*
. - S’il n’existe aucune sortie,
known_hosts
ne contient pas d’entrée correspondante. Suivez les instructions de la section Configurer l’agent d’ingestion Azure Operator Insights pour ajouter une entréeknown_hosts
pour le serveur SFTP.
- Sur la machine virtuelle de l’agent, exécutez
Aucun fichier n’est chargé dans Azure Operator Insights
Symptômes : aucune donnée ne s’affiche dans Azure Data Explorer. Les journaux d’activité de catégorie Ingestion
n’apparaissent pas dans données de surveillance Azure Operator Insights ou contiennent des erreurs. Le Nombre de lignes ingérées métrique de qualité des données pour le type de données approprié est égal à zéro.
- Vérifiez que l’agent s’exécute sur toutes les machines virtuelles et ne signale pas d’erreurs dans les journaux.
- Vérifiez que les fichiers existent à l’emplacement correct sur le serveur SFTP et qu’ils ne sont pas exclus en raison de la configuration de la source de fichier (consultez la section Fichiers manquants).
- Vérifiez que l’utilisateur SFTP configuré peut lire tous les répertoires sous le
base_path
dont la configuration source de fichier n’exclut pas. - Vérifiez la connectivité réseau et la configuration du pare-feu entre la machine virtuelle de l’agent d’ingestion et le compte de stockage d’entrée du produit de données.
Fichiers manquants
Symptômes : les données sont manquantes dans Azure Data Explorer. Les journaux de catégorie Ingestion
dans les données de surveillance Azure Operator Insights sont inférieurs aux attentes ou contiennent des erreurs. Le Nombre de lignes ingérées métrique de qualité des données pour le type de données approprié est inférieur à ce qui est prévu.
- Vérifiez que l’agent s’exécute sur toutes les machines virtuelles et ne signale pas d’erreurs dans les journaux. Recherchez dans les journaux du package de diagnostic le nom du fichier manquant pour rechercher des erreurs liées à ce fichier.
- Vérifiez que les fichiers existent sur le serveur SFTP et qu’ils ne sont pas exclus en raison de la configuration de la source de fichier. Vérifiez la configuration de la source du fichier et vérifiez que :
- Les fichiers existent sur le serveur SFTP sous le chemin d’accès défini dans
base_path
. Vérifiez qu’il n’existe aucun lien symbolique dans les chemins d’accès des fichiers à charger : l’agent d’ingestion ignore les liens symboliques. - L’heure de « dernière modification » des fichiers est au moins
settling_time
secondes antérieures à l’heure de l’exécution de chargement la plus récente pour cette source de fichier. - L’heure de « dernière modification » des fichiers est postérieure à
exclude_before_time
(le cas échéant). - Le chemin d’accès au fichier relatif à
base_path
correspond à l’expression régulière donnée parinclude_pattern
(le cas échéant). - Le chemin d’accès au fichier relatif à
base_path
ne correspond pas à l’expression régulière donnée parexclude_pattern
(le cas échéant).
- Les fichiers existent sur le serveur SFTP sous le chemin d’accès défini dans
- Si des fichiers récents sont manquants, vérifiez que les journaux de l’agent dans le package de diagnostics vérifient que l’agent d’ingestion a effectué une exécution de chargement pour la source au moment prévu. Le paramètre
cron
dans la configuration source donne la planification attendue. - Vérifiez que la machine virtuelle de l’agent n’est pas surchargée, pour surveiller l’utilisation du processeur et de la mémoire. En particulier, assurez-vous qu’aucun autre processus ne prend des ressources à partir de la machine virtuelle.
Les fichiers sont chargés plusieurs fois
Symptômes : les données en double s’affichent dans Azure Operator Insights.
- Vérifiez si l'agent d'ingestion a rencontré une erreur réessayable dans le journal du package de diagnostics lors d'un téléchargement précédent, puis a réessayé ce téléchargement plus de 24 heures après le dernier téléchargement réussi. Dans ce cas, l’agent peut charger des données en double pendant la nouvelle tentative. La duplication des données doit affecter uniquement la nouvelle tentative.
- Vérifiez que les sources de fichiers définies dans le fichier config font référence à des ensembles de fichiers qui ne se chevauchent pas. Si plusieurs sources de fichiers sont configurées pour extraire des fichiers à partir du même emplacement sur le serveur SFTP, utilisez les champs de configuration
include_pattern
etexclude_pattern
pour définir des ensembles distincts de fichiers que chaque source de fichier doit prendre en compte. - Si vous exécutez plusieurs instances de l’agent d’ingestion SFTP, vérifiez que les sources de fichiers configurées pour chaque agent ne chevauchent pas les sources de fichiers sur un autre agent. En particulier, recherchez la configuration source du fichier qui a été copiée accidentellement à partir de la configuration d’un autre agent.
- Si vous avez récemment modifié le pipeline
id
pour une source de fichier configurée, utilisez le champexclude_before_time
pour éviter que les fichiers soient rechargés avec le nouveau pipelineid
. Pour obtenir des instructions, consultez la section Modifier la configuration des agents d’ingestion pour Azure Operator Insights.
Contenu connexe
Découvrez comment :
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez :Soumettre et afficher des commentaires pour