Schéma du journal Container Insights

Container Insights stocke les données de journal collectées dans une table nommée ContainerLogV2. Cet article décrit le schéma de cette table, sa comparaison et sa migration depuis la table ContainerLog héritée.

Important

ContainerLogV2 est le schéma par défaut avec les versions 2.54.0 et ultérieures de ConfigMap pour l’interface CLI. ContainerLogV2 est le schéma d’ingestion par défaut pour les clients qui intègrent Container Insights à l’authentification d’identité managée en utilisant l’intégration ARM, Bicep, Terraform, Policy et du portail. 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.

La prise en charge de la table ContainerLog sera mise hors service le 30 septembre 2026.

Comparaison des tables

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 - LogLevel1 - KubernetesMetadata2
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.

¹Si LogMessage est un JSON valide et a une clé nommée level, sa valeur sera utilisée. Sinon, nous utilisons une approche de correspondance de mot clé basée sur regex pour inférer LogLevel à partir du LogMessage lui-même. Notez qu’il est possible que des classifications soient incorrectes, car cette valeur est inférée.

²KubernetesMetadata est une colonne facultative et une collection de ce champ peut être activée avec la fonctionnalité Métadonnées Kubernetes. La valeur de ce champ est JSON et il contient des champs tels que podLabels, podAnnotations, podUid, Image, ImageTag et Image repo.

³Configuration des DCR non prise en charge pour les clusters utilisant des clusters basés sur l’authentification du principal de service. Pour utiliser cette expérience, migrez vos clusters avec un principal de service vers une 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 JSON valide. Pour un meilleur niveau de performance, nous vous recommandons d’émettre des journaux de conteneur au format JSON.

Évaluez l’impact sur les alertes existantes

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.

Pour analyser les alertes qui référencent la table ContainerLog, exécutez la requête Azure Resource Graph suivante :

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

Activer le schéma ContainerLogV2

Vous pouvez activer le schéma ContainerLogV2 d’un cluster à l’aide 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. Les journaux stdout et stderr sont ingérés dans la table ContainerLog seulement quand la DCR et ConfigMap sont tous deux explicitement définis sur Désactivé.

Filtrage des métadonnées et des journaux Kubernetes

Le filtrage des métadonnées et des journaux Kubernetes améliore le schéma ContainerLogsV2 avec d’autres métadonnées Kubernetes telles que PodLabels, PodAnnotations, PodUid, Image, ImageID, ImageRepo et ImageTag. En outre, la fonctionnalité Filtrage des journaux fournit des fonctionnalités de filtrage pour les conteneurs de charge de travail et de plateforme (c’est-à-dire des espaces de noms système). Avec ces fonctionnalités, les utilisateurs obtiennent un contexte plus riche et une visibilité améliorée de leurs charges de travail.

Fonctionnalités clés

• Schéma ContainerLogV2 amélioré avec des champs de métadonnées Kubernetes : Métadonnées des journaux Kubernetes introduit d’autres champs de métadonnées facultatifs qui améliorent l’expérience de résolution des problèmes avec des requêtes Log Analytics simples et supprime la nécessité de joindre d’autres tables. Ces champs incluent des informations essentielles telles que « PodLabels », « PodAnnotations », « PodUid », « Image », « ImageID », « ImageRepo » et « ImageTag ». En ayant ce contexte à portée de main, les utilisateurs peuvent accélérer la résolution des problèmes et les identifier rapidement.

• Configuration de liste d’inclusion personnalisée : les utilisateurs peuvent personnaliser de nouveaux champs de métadonnées qu’ils souhaitent voir via la modification du fichier configmap. Notez que tous les champs de métadonnées sont collectés par défaut quand la metadata_collection est activée ; si vous souhaitez sélectionner des champs spécifiques, supprimez les marques de commentaire des include_fields et spécifiez les champs à collecter.

• Schéma ContainerLogV2 amélioré avec le niveau de journal : les utilisateurs peuvent désormais évaluer l’intégrité de l’application en fonction de niveaux de gravité codés par couleur, tels que CRITICAL, ERROR, WARNING, INFO, DEBUG, TRACE ou UNKNOWN (CRITIQUE, ERREUR, AVERTISSEMENT, INFORMATION, DÉBOGAGE, TRACE ou INCONNU). C’est un outil crucial pour la réponse aux incidents et la surveillance proactive. En distinguant visuellement les niveaux de gravité, les utilisateurs peuvent localiser rapidement les ressources affectées. Le système codé par couleur simplifie le processus d’investigation et permet aux utilisateurs d’explorer à des niveaux plus détaillés en sélectionnant le panneau pour une expérience d’exploration permettant un débogage plus approfondi. Cependant, il est important de noter que cette fonctionnalité s’applique seulement lors de l’utilisation de Grafana. Si vous utilisez l’espace de travail Log Analytics, LogLevel est simplement une autre colonne de la table ContainerLogV2.

• Filtrage des journaux basé sur les annotations pour les charges de travail : technique de filtrage efficace des journaux via des annotations des pods. Les utilisateurs peuvent se concentrer sur des informations pertinentes sans avoir à éliminer le bruit. Le filtrage basé sur des annotations permet aux utilisateurs 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 d’analyse des journaux.

• Filtrage des journaux basés sur ConfigMap pour les journaux de plateforme (espaces de noms Kubernetes système) : 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 au minimum le coût de 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. Par exemple, considérez le conteneur coredns de l’espace de noms kube-system. Pour collecter des journaux (stdout et stderr) exclusivement auprès du conteneur coredns de kube-system, vous pouvez activer les paramètres suivants dans le fichier configmap.

• Tableau de bord Grafana pour la visualisation : le tableau de bord Grafana non seulement montre des visualisations codées par couleur des niveaux de journal allant de CRITICAL à UNKNOWN (CRITIQUE à INCONNU), mais permet également d’explorer en profondeur le volume des journaux, le débit des journaux, les enregistrements de journal, les journaux. Les utilisateurs peuvent obtenir des analyses chronologiques, des insights dynamiques dans les tendances au fil du temps pour un niveau de journal et une surveillance en temps réel cruciale. Nous fournissons également une ventilation détaillée par ordinateur, par pod et par conteneur, ce qui permet une analyse approfondie et la résolution ciblée des problèmes. Enfin, dans la nouvelle expérience des tables de journaux, les utilisateurs peuvent visualiser des détails approfondis avec une vue étendue, et visualiser les données de chaque colonne et effectuer une exploration détaillée des informations qu’ils veulent voir.

Voici une vidéo présentant le tableau de bord Grafana :

Comment activer le filtrage des métadonnées et des journaux Kubernetes

Prérequis

1. Migrez vers l’authentification par identité managée. En savoir plus.

2. Vérifiez que ContainerLogV2 est activé. Ce schéma est activé par défaut sur les clusters d’authentification par identité managée. Si ce n’est pas le cas, activer le schéma ContainerLogV2.

Limites

Le tableau de bord Grafana ContainerLogV2 n’est pas pris en charge avec la référence SKU Journaux de base sur la table ContainerLogV2.

Activer les métadonnées Kubernetes

1. Téléchargez le fichier configmap et changez les paramètres de false en true, comme indiqué dans la capture d’écran ci-dessous. Notez que tous les champs de métadonnées pris en charge sont collectés par défaut. Si vous souhaitez collecter des champs spécifiques, spécifiez les champs requis dans include_fields.

2. Appliquez le fichier ConfigMap. Consultez Configurer le fichier configmap pour en savoir plus sur le déploiement et la configuration du fichier ConfigMap.

3. Après quelques minutes, les données doivent commencer à arriver dans votre table ContainerLogV2 avec les métadonnées des journaux Kubernetes, comme illustré dans la capture d’écran ci-dessous.

Intégrer à l’expérience du tableau de bord Grafana

1. Sous l’onglet Insights, sélectionnez Surveiller les paramètres et intégrer au tableau de bord Grafana avec la version 10.3.4+

2. Vérifiez que vous disposez de l’un des rôles Administrateur/Éditeur/Lecteur Grafana en consultant Contrôle d’accès (IAM). Si ce n’est pas le cas, veuillez les ajouter.

3. Vérifiez que votre instance Grafana a accès à l’espace de travail Azure Logs Analytics. S’il n’y a pas accès, vous devez accorder au rôle Lecteur de surveillance d’instance Grafana l’accès à votre espace de travail Logs Analytics.

4. Accédez à votre espace de travail Grafana et importez le tableau de bord ContainerLogV2 depuis la galerie Grafana.

5. Sélectionnez vos informations pour DataSource, Subscription, ResourceGroup, Cluster, Namespace et Labels (Source de données, Abonnement, Groupe de ressources, Cluster, Espace de travail et Étiquettes). Le tableau de bord se remplit alors, comme illustré dans la capture d’écran ci-dessous.

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.

Activer le filtrage basé sur les annotations

Suivez les étapes mentionnées ci-dessous pour activer le filtrage basé sur les annotations. Vous trouvez le lien ici une fois que la documentation associée du filtrage est publiée.

1. Téléchargez le fichier configmap et changez les paramètres de false en true, comme illustré dans la capture d’écran ci-dessous.

2. Appliquez le fichier ConfigMap. Consultez Configurer le fichier configmap pour en savoir plus sur le déploiement et la configuration du fichier ConfigMap.

3. Ajoutez les annotations requises sur votre spécification des pods de charge de travail. Le tableau suivant montre les différentes annotations possibles et des descriptions de ce qu’elles font.

Annotation	Description
fluentbit.io/exclude: "true"	Exclut les flux stdout et stderr sur tous les conteneurs du pod
fluentbit.io/exclude_stdout: "true"	Exclut seulement le flux stdout sur tous les conteneurs du pod
fluentbit.io/exclude_stderr: "true"	Exclut seulement le flux stderr sur tous les conteneurs du pod
fluentbit.io/exclude_container1: "true"	Exclut les flux stdout et stderr seulement pour le conteneur container1 du pod
fluentbit.io/exclude_stdout_container1: "true"	Exclure seulement stdout seulement pour le conteneur container1 dans le pod

Remarque

Ces annotations sont basées sur Fluent Bit. Si vous utilisez votre propre solution de collecte de journaux Fluent Bit avec le filtre de plug-in Kubernetes et l’exclusion basée sur les annotations, il va arrêter de collecter les journaux auprès de Container Insights et de votre solution.

Voici un exemple d’annotation fluentbit.io/exclude: "true" dans la spécification de pod :

apiVersion: v1 
kind: Pod 
metadata: 
 name: apache-logs 
 labels: 
  app: apache-logs 
 annotations: 
  fluentbit.io/exclude: "true" 
spec: 
 containers: 
 - name: apache 
  image: edsiper/apache_logs 

Filtrage des journaux basés sur ConfigMap pour les journaux de plateforme (espaces de noms Kubernetes système)

1. Téléchargez le fichier configmap et changez les paramètres liés à collect_system_pod_logs et exclude_namespaces.

Par exemple, pour collecter les journaux stdout et stderr du conteneur coredns dans l’espace de noms kube-system, vérifiez que l’espace de noms kube-system n’est pas dans exclude_namespaces et que cette fonctionnalité est limitée uniquement aux espaces de noms système suivants : kube-system, gatekeeper-system, calico-system, azure-arc, kube-public et kube-node-lease.

2. Appliquez le fichier ConfigMap. Consultez Configurer le fichier configmap pour en savoir plus sur le déploiement et la configuration du fichier ConfigMap.

Journalisation sur plusieurs lignes dans Container Insights

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