Schéma du journal Container Insights

Article
2025-05-08

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`¹ - `KubernetesMetadata`²
Intégration	Configurable uniquement via ConfigMap.	Configurable via ConfigMap et les DCR. ³
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.
Multiligne	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.

¹ 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.

²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.

³ La configuration DCR nécessite l’authentification par identité managée.

Remarque

Le LogMessage champ est dynamique et prend en charge l’ingestion des formats de chaîne JSON et en texte brut. L’exportation des données de journal vers Event Hub et le compte de stockage est prise en charge si le json entrant LogMessage est valide ou une chaîne simple valide.

Si le LogMessage JSON est malformé, ces messages de journal sont alors ingérés avec l’échappement. Par défaut, les messages de journal supérieurs à 16 Ko sont tronqués. Avec la journalisation multiligne activée, les messages de journalisation supérieurs à 64 Ko sont tronqués.

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.

Remarque

Le tableau de bord Grafana de filtrage des métadonnées et des journaux Kubernetes ne prend actuellement pas en charge les journaux de base.

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 nomme KubernetesMetadata, 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, informationdé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 noms kube-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. Activez la journalisation multiligne avec ConfigMap comme décrit dans Configurer la collecte de données dans Container Insights à l’aide de ConfigMap.

Remarque

Le configmap propose désormais une option de spécification de langage qui vous permet de sélectionner uniquement les langues qui vous intéressent. Cette fonctionnalité peut être activée en modifiant les langues dans l’option stacktrace_languages de configmap.

Limites

La journalisation multiligne n’assemble que les traces d’exceptions provenant des conteneurs utilisant Java, Python, .NET et Go. D’autres entrées de journal multiligne, y compris les exceptions personnalisées et les messages de journal arbitraires, ne sont pas regroupées.
Si la ligne de journal dépasse 16 Ko, elle ne sera pas tronquée par défaut par le runtime de conteneur, et la ligne de journal sera prise en charge jusqu’à 64 Ko.