Schéma du journal Container Insights
Container Insights stocke les données de journal collectées dans une table appelée ContainerLogV2 dans un espace de travail Log Analytics. Cet article décrit le schéma de cette table et des options de configuration pour celle-ci. Il compare également cette table à la table ContainerLog héritée et fournit des détails pour la migration à partir de celle-ci.
Comparaison des tables
ContainerLogV2 est le schéma par défaut pour l’interface de ligne de commande version 2.54.0 et ultérieure. Il s’agit de la table par défaut pour les clients qui intègrent Container Insights avec l’authentification par identité managée. ContainerLogV2 peut être explicitement activé via l’interface CLI version 2.51.0 ou ultérieure à l’aide des paramètres de collecte de données.
Important
La prise en charge de la table ContainerLog sera mise hors service le 30 septembre 2026.
Le tableau suivant souligne les principales différences entre l’utilisation des schémas ContainerLogV2 et ContainerLog.
Différences de fonctionnalités | ContainerLog | ContainerLogV2 |
---|---|---|
schéma | Détails sur ContainerLog. | Détails sur ContainerLogV2. Les colonnes supplémentaires sont : - ContainerName - PodName - PodNamespace - LogLevel 1- KubernetesMetadata 2 |
Intégration | Configurable uniquement via ConfigMap. | Configurable via ConfigMap et les DCR. 3 |
Tarification | Compatible uniquement avec des journaux d’analyse à plein tarif. | Prend en charge le niveau des journaux de base à faible coût en plus des journaux d’analyse. |
Interrogation | Nécessite plusieurs opérations de jointure avec des tables d’inventaire pour des requêtes standard. | Inclut des métadonnées de pod et de conteneur supplémentaires afin de réduire la complexité des requêtes et les opérations de jointure. |
Multiline | Non prises en charge, les entrées multilignes sont fractionnées en plusieurs lignes. | Prise en charge de la journalisation multiligne afin d’autoriser des entrées uniques consolidées pour une sortie multiligne. |
1 Si LogMessage
est un fichier JSON valide et présente une clé nommée level
, sa valeur sera utilisée. Dans le cas contraire, la correspondance de mot clé basée sur les expressions régulières est utilisée pour déduire LogLevel
à partir de LogMessage
. Cette inférence peut entraîner des classifications incorrectes. LogLevel
est un champ de chaîne avec une valeur d’intégrité telle que CRITICAL
, , ERROR
, WARNING
, INFO
, DEBUG
, TRACE
ou UNKNOWN
.
2 KubernetesMetadata
est une colonne facultative activée par les métadonnées Kubernetes. La valeur de ce champ est JSON avec les champs podLabels
, podAnnotations
, podUid
, Image
, ImageTag
et Image repo
.
3 La configuration DCR nécessite l’authentification par identité managée.
Remarque
L’exportation vers Event Hub et le compte de stockage n’est pas prise en charge si le LogMessage
entrant n’est pas un fichier JSON valide. Pour des performances optimales, émettez des journaux de conteneur au format JSON.
Activer le schéma ContainerLogV2
Activez le schéma ContainerLogV2 d’un cluster au moyen des DCR (Règles de collecte de données) du cluster ou de ConfigMap. Si les deux paramètres sont activés, ConfigMap est prioritaire. La table ContainerLog
est utilisée uniquement lorsque les DCR et ConfigMap sont explicitement paramétrés comme désactivés.
Avant d’activer le schéma ContainerLogsV2, vous devez déterminer si vous avez des règles d’alerte reposant sur la table ContainerLog. Ces alertes doivent être mises à jour pour utiliser la nouvelle table. Exécutez la requête Azure Resource Graph suivante pour scanner les règles d’alertes qui font référence à la table ContainerLog
.
resources
| where type in~ ('microsoft.insights/scheduledqueryrules') and ['kind'] !in~ ('LogToMetric')
| extend severity = strcat("Sev", properties["severity"])
| extend enabled = tobool(properties["enabled"])
| where enabled in~ ('true')
| where tolower(properties["targetResourceTypes"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["targetResourceType"]) matches regex 'microsoft.operationalinsights/workspaces($|/.*)?' or tolower(properties["scopes"]) matches regex 'providers/microsoft.operationalinsights/workspaces($|/.*)?'
| where properties contains "ContainerLog"
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc
Filtrage des métadonnées et des journaux Kubernetes
Le filtrage des métadonnées et des journaux Kubernetes agrandit le schéma ContainerLogsV2 avec des métadonnées Kubernetes supplémentaires. La fonctionnalité de filtrage des journaux fournit des fonctionnalités de filtrage pour les conteneurs de charge de travail et de plateforme. Ces fonctionnalités vous donnent un contexte plus explicite et une visibilité améliorée de vos charges de travail.
Fonctionnalités
Schéma ContainerLogV2 amélioré Lorsque les métadonnées des journaux Kubernetes sont activées, une colonne s’ajoute à
ContainerLogV2
. Elle se nommeKubernetesMetadata
, améliore la résolution des problèmes avec des requêtes de journal simples et supprime la nécessité d’association à d’autres tables. Les champs de cette colonne sont les suivants :PodLabels
,PodAnnotations
,PodUid
,Image
,ImageID
,ImageRepo
,ImageTag
. Ces champs améliorent l’expérience de résolution des problèmes au moyen de requêtes de journal sans qu’une association à d’autres tables soit nécessaire. Voir ci-dessous pour plus d’informations sur l’activation de la fonctionnalité de métadonnées Kubernetes.Niveau de journal Cette fonctionnalité ajoute une colonne
LogLevel
à ContainerLogV2 où les valeurs peuvent être : critique, erreur, avertissement, information débogage, suiviou inconnu. Cela vous permet d’évaluer l’intégrité de l’application en fonction du niveau de gravité. En ajoutant le tableau de bord Grafana, vous pouvez visualiser les tendances au niveau du journal au fil du temps et identifier rapidement les ressources affectées.Tableau de bord Grafana pour la visualisation Le tableau de bord Grafana fournit une visualisation à code de couleurs du niveau de journal et fournit également des informations sur le volume du fichier journal, le taux de journalisation, les enregistrements de journal et les journaux. Vous pouvez obtenir des analyses chronologiques, des informations dynamiques sur les tendances au fil du temps pour un niveau de journal et une surveillance en temps réel cruciale. Le tableau de bord fournit également une répartition détaillée par ordinateur, par pod et par conteneur, ce qui permet une analyse approfondie et une résolution ciblée des problèmes. Voir ci-dessous pour plus d’informations sur l’installation du tableau de bord Grafana.
Filtrage des journaux basé sur les annotations pour les charges de travail Technique de filtrage efficace des journaux via des annotations des pods. Elle vous permet de vous concentrer sur des informations pertinentes sans avoir à éliminer le bruit. Le filtrage basé sur des annotations vous permet d’exclure la collecte de journaux pour certains pods et certains conteneurs en annotant le pod, ce qui permet de réduire considérablement le coût de Log Analytics. Pour plus d’informations sur la configuration du filtrage basé sur les annotations, consultez Filtrage des journaux basé sur les annotations.
Filtrage des journaux basés sur ConfigMap pour les journaux de plateforme (espaces de noms de système Kubernetes) Les journaux de plateforme sont émis par des conteneurs dans les espaces de noms système (ou des espaces restreints similaires). Par défaut, tous les journaux de conteneur de l’espace de noms système sont exclus pour réduire le coût des données dans votre espace de travail Log Analytics. Cependant, dans des scénarios de résolution des problèmes spécifiques, les journaux de conteneur du conteneur système jouent un rôle crucial. L’un des exemples est le conteneur
coredns
dans l’espace de nomskube-system
.
Activer les métadonnées Kubernetes
Important
La collecte des métadonnées Kubernetes nécessite l’authentification par identité managée et ContainerLogsV2
Activez les métadonnées Kubernetes au moyen de ConfigMap avec les paramètres suivants. Tous les champs de métadonnées sont collectés par défaut lorsque metadata_collection
est activé. Supprimez include_fields
pour indiquer les champs individuels à collecter.
[log_collection_settings.metadata_collection]
enabled = true
include_fields = ["podLabels","podAnnotations","podUid","image","imageID","imageRepo","imageTag"]
Après quelques minutes, la colonne KubernetesMetadata
doit être incluse avec toutes les requêtes de journal pour la table ContainerLogV2
, comme indiqué ci-dessous.
Installer le tableau de bord Grafana
Important
Si vous avez activé Grafana en suivant les instructions de Activer la surveillance pour les clusters Kubernetes, votre instance Grafana doit déjà avoir accès à votre espace de travail Azure Monitor pour les métriques Prometheus. Le tableau de bord des métadonnées des journaux Kubernetes nécessite également l’accès à votre espace de travail Log Analytics, lequel contient des données de journal. Consultez Comment modifier les autorisations d’accès à Azure Monitor pour savoir comment octroyer le rôle de Lecteur de surveillance à votre instance Grafana pour votre espace de travail Log Analytics.
Importez le tableau de bord à partir de la galerie Grafana dans Tableau de bord ContainerLogV2. Vous pouvez ensuite ouvrir le tableau de bord et sélectionner des valeurs pour Source de données, Abonnement, Groupe de ressources, Cluster, Espace de noms et Étiquettes.
Remarque
Quand vous chargez le tableau de bord Grafana pour la première fois, il peut indiquer quelques erreurs en raison de variables qui ne sont pas encore sélectionnées. Pour éviter que cela ne se reproduise, enregistrez le tableau de bord après avoir sélectionné un ensemble de variables pour en faire l’ensemble par défaut lors de la première ouverture.
Journalisation multiligne
Une fois la journalisation multiligne activée, les journaux de conteneur précédemment fractionnés sont assemblés et envoyés en tant qu’entrées uniques vers la table ContainerLogV2. Si la ligne de journal assemblée est supérieure à 64 Ko, elle sera tronquée en raison des limites de l’espace de travail Log Analytics. Cette fonctionnalité prend également en charge les traces .NET, Go, Python et Java, qui apparaissent en tant qu’entrées uniques dans la table ContainerLogV2. Activez la journalisation multiligne avec ConfigMap comme décrit dans Configurer la collecte de données dans Container Insights à l’aide de ConfigMap.
Remarque
La carte de configuration (configmap) comporte désormais une option de spécification de la langue, qui permet aux clients de sélectionner uniquement les langues qui les intéressent. Cette fonctionnalité peut être activée en modifiant les langues dans l’option stacktrace_languages de configmap.
Les captures d’écran suivantes montrent la journalisation multiligne de la trace d’exceptions Go :
Journalisation multiligne désactivée
Journalisation multiligne activée
Trace Java
Trace Python
Étapes suivantes
- Configurer les Journaux d’activité basiques pour ContainerLogv2.
- Découvrez comment interroger des données à partir de ContainerLogV2
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