Superviser et résoudre les problèmes de collecte de données DCR dans Azure Monitor

Article
11/05/2024

Cet article fournit des métriques et des journaux détaillés que vous pouvez utiliser pour superviser les performances et résoudre les problèmes liés à la collecte de données dans Azure Monitor. Cette télémétrie est actuellement disponible pour les scénarios de collecte de données définis par des règles de collecte de données (DCR), tels que l’agent Azure Monitor et l’API d’ingestion de journaux.

Important

Cet article fait uniquement référence aux scénarios de collecte de données qui utilisent des DCR, notamment les suivants :

Journaux collectés à l’aide de l’agent Azure Monitor (AMA)
Journaux ingérés à l’aide de l’API d’ingestion de journaux
Journaux collectés par d’autres méthodes qui utilisent une DCR de transformation d’espace de travail

Consultez la documentation relative à d’autres scénarios pour obtenir toutes les informations de monitoring et de résolution des problèmes qui peuvent être disponibles.

Les fonctionnalités de diagnostic DCR incluent les métriques et les journaux d’erreurs émis pendant le traitement des journaux. Les métriques DCR fournissent des informations sur le volume de données ingérées, le nombre et la nature des éventuelles erreurs de traitement, et les statistiques liées à la transformation des données. Des journaux d’erreurs DCR sont générés chaque fois que le traitement des données échoue et que les données n’atteignent pas leur destination.

Journaux des erreurs DCR

Des journaux d’erreurs sont générés lorsque les données atteignent le pipeline d’ingestion Azure Monitor, mais ne parviennent pas à atteindre leur destination. Voici quelques exemples de conditions d’erreur :

Erreurs de remise des journaux
Erreurs de transformation où la structure des journaux rend la transformation KQL non valide
Appels à l’API d’ingestion de journaux :
- Avec une réponse HTTP autre que 200/202.
- Avec une charge utile contenant des données incorrectes.
- Avec une charge utile supérieure aux limites d’ingestion.
- Avec limitation due à un dépassement des limites d’appel d’API

Pour éviter une journalisation excessive d’erreurs persistantes liées au même flux de données, certaines erreurs ne sont enregistrées qu’un nombre limité de fois chaque heure, suivie d’un message d’erreur récapitulatif. L’erreur est ensuite désactivée jusqu’à la fin de l’heure. Le nombre de fois qu’une erreur donnée est enregistrée peut varier en fonction de la région dans laquelle la DCR est déployée.

Certaines erreurs d’ingestion de journaux ne seront pas journalisées car elles ne peuvent pas être associées à une DCR. Les erreurs suivantes peuvent ne pas être journalisées :

Échecs causés par un URI d’appel incorrect (code de réponse HTTP 404)
Certaines erreurs de serveur interne (code de réponse HTTP 500)

Activer les journaux d’erreurs DCR

Les journaux d’erreurs DCR sont implémentés en tant que journaux de ressources dans Azure Monitor. Activez la collecte de journaux en créant un paramètre de diagnostic pour la DCR. Chaque DCR nécessite son propre paramètre de diagnostic. Pour connaître le processus détaillé, consultez Créer des paramètres de diagnostic dans Azure Monitor. Sélectionnez la catégorie Enregistrer les erreurs et Envoyer à l’espace de travail Log Analytics. Vous pouvez sélectionner le même espace de travail que celui utilisé par la DCR, ou consolider tous vos journaux d’erreurs dans un espace de travail unique.

Récupérer les journaux d’erreurs DCR

Les journaux d’erreurs sont écrits dans la table DCRLogErrors dans l’espace de travail Log Analytics que vous avez spécifié dans le paramètre de diagnostic. Voici des exemples de requêtes que vous pouvez utiliser dans Log Analytics pour récupérer ces journaux.

Récupérer tous les journaux d’erreurs pour une DCR particulière

DCRLogErrors
| where _ResourceId == "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"

Récupérer tous les journaux d’erreurs pour un flux d’entrée particulier dans une DCR particulière

DCRLogErrors
| where _ResourceId == "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"
| where InputStreamId == "Custom-MyTable_CL"

Métriques de DCR

Les métriques de DCR sont collectées automatiquement pour toutes les DCR, et vous pouvez les analyser à l’aide de Metrics Explorer, comme les métriques de plateforme pour d’autres ressources Azure. Le flux d’entrée est inclus en tant que dimension. Par conséquent, si vous disposez d’une DCR avec plusieurs flux d’entrée, vous pouvez les analyser chacune par filtrage ou fractionnement. Certaines métriques incluent d’autres dimensions, comme indiqué dans le tableau ci-dessous.

Mesure	Dimensions	Description
Logs Ingestion Bytes per Min	Flux d'entrée	Nombre total d’octets reçus par minute.
Logs Ingestion Requests per Min	Flux d'entrée Code de réponse HTTP	Nombre d’appels reçus par minute.
Logs Rows Dropped per Min	Flux d'entrée	Nombre de lignes de journaux supprimées pendant le traitement par minute. Cela inclut les lignes supprimées en raison de critères de filtrage dans la transformation KQL et les lignes supprimées en raison d’erreurs.
Logs Rows Received per Min	Flux d'entrée	Nombre de lignes de journaux reçues pour traitement par minute.
Logs Transformation Duration per Min	Flux d'entrée	Durée moyenne d’exécution de transformation KQL par minute. Représente l’efficacité du code de transformation KQL. Les flux de données avec une durée d’exécution de transformation plus longue peuvent rencontrer des retards dans le traitement des données et une plus grande latence des données.
Logs Transformation Errors per Min	Flux d'entrée Type d’erreur	Nombre d’erreurs de traitement rencontrées par minute.

Résolution des problèmes courants

Si des données attendues sont manquantes dans votre espace de travail Log Analytics, suivez ces étapes de base pour résoudre le problème. Cela part du principe que vous avez activé la journalisation DCR comme décrit ci-dessus.

Vérifiez des métriques telles que Logs Ingestion Bytes per Min et Logs Rows Received per Min pour être certain que les données atteignent Azure Monitor. Si ce n’est pas le cas, vérifiez votre source de données pour être certain qu’elle envoie des données comme prévu.
Vérifiez Logs Rows Dropped per Min pour voir si des lignes sont supprimées. Cela peut ne pas indiquer une erreur, car les lignes peuvent être supprimées par une transformation. Toutefois, si les lignes supprimées sont identiques à Logs Rows Dropped per Min, cela signifie qu’aucune donnée ne sera ingérée dans l’espace de travail. Examinez Logs Transformation Errors per Min pour voir s’il existe des erreurs de transformation.
Vérifiez Logs Transformation Errors per Min pour déterminer s’il existe des erreurs liées aux transformations appliquées aux données entrantes. Ces erreurs peuvent être dues aux modifications apportées à la structure de données ou à la transformation elle-même.
Vérifiez DCRLogErrors pour voir si des erreurs d’ingestion ont été journalisées. Cela peut fournir des détails supplémentaires pour identifier la cause racine du problème.

Monitoring de l’ingestion de journaux

Les signaux suivants peuvent être utiles pour superviser l’intégrité de la collecte de journaux avec des DCR. Créez des règles d’alerte pour identifier ces conditions.

Signal	Causes possibles et actions à mener
Nouvelles entrées dans `DCRErrorLogs` ou changement soudain de `Log Transform Errors`.	- Problèmes liés à la configuration de l’API d’ingestion de journaux comme l’authentification, l’accès aux DCR ou DCE, ou des problèmes de charge utile des appels. - Modifications apportées à la structure de données provoquant des échecs de transformation KQL. - Modifications apportées à la configuration de destination des données provoquant des échecs de remise de données.
Changement soudain de `Logs Ingestion Bytes per Min`	- Modifications apportées à la configuration de l’ingestion de journaux sur le client, y compris les paramètres AMA. - Modifications apportées à la structure des journaux envoyés.
Changement soudain du rapport entre `Logs Ingestion Bytes per Min` et `Logs Rows Received per Min`	- Modifications apportées à la structure des journaux envoyés. Examinez les modifications pour être certain que les données sont correctement traitées avec la transformation KQL.
Changement soudain de `Logs Transformation Duration per Min`	- Modifications de la structure des journaux affectant l’efficacité des critères de filtrage des journaux définis dans la transformation KQL. Examinez les modifications pour être certain que les données sont correctement traitées avec la transformation KQL.
`Logs Ingestion Requests per Min` ou `Logs Ingestion Bytes per Min` approchant les limites du service d’API d’ingestion de journaux.	- Examinez et optimisez votre configuration DCR pour éviter la limitation.

Alertes

Plutôt que de résoudre les problèmes de manière réactive, créez des règles d’alerte pour être avertis de manière proactive lorsqu’une condition d’erreur potentielle se produit. Le tableau suivant fournit des exemples de règles d’alerte que vous pouvez créer pour superviser l’ingestion de journaux.

Condition	Détails de l’alerte
Changement soudain du nombre de lignes supprimées	Règle d’alerte de métrique utilisant un seuil dynamique pour `Logs Rows Dropped per Min`.
Nombre d’appels d’API approchant les limites du service	Règle d’alerte de métrique utilisant un seuil statique pour `Logs Ingestion Requests per Min`. Définissez un seuil proche de 12 000, ce qui correspond à la limite de service pour le nombre maximal de requêtes par minute par DCR.
Journaux d’erreurs	Alerte de requête de journal utilisant `DCRLogErrors`. Utilisez une mesure Lignes de table et une Valeur de seuil de 1 pour être alerté chaque fois que des erreurs sont enregistrées.

Partager via