Configurer le schéma ContainerLogV2

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. Ce schéma est la table par défaut pour les clients qui intègrent Container Insights avec l’authentification d’identité managée. Activez ContainerLogV2 explicitement 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 prend fin le 30 septembre 2026. Les clients doivent migrer vers ContainerLogV2 avant cette date. Après la mise hors service, Microsoft peut continuer à accepter des données pendant une période de transition limitée afin de réduire les interruptions pour les clients existants. Toutefois, l’expérience de mise hors service ne reçoit plus de support, de correctifs de bogues ou de nouveaux investissements. Les clients ne doivent pas compter sur la période de transition et doivent effectuer la migration dès que possible. Pour changer de table, consultez Activer le schéma ContainerLogV2.

Le tableau suivant souligne les principales différences entre l’utilisation des schémas ContainerLogV2 et ContainerLog.

Différences de fonctionnalités	Journal de conteneurs	ContainerLogV2
schéma	Détails sur ContainerLog.	Détails sur ContainerLogV2. Les colonnes supplémentaires sont : - ContainerName - PodName - PodNamespace - LogLevel 1 - KubernetesMetadata 2
Mise en route	Configurable uniquement via ConfigMap.	Configurable via ConfigMap et les DCR. 3
Tarifs	Compatible uniquement avec des journaux d’analyse à plein tarif.	Prend en charge le niveau Basic Logs à faible coût en plus des journaux d’activité d’analytique.
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.

¹ S’il LogMessage est json valide et a une clé nommée level, sa valeur est utilisée. Dans le cas contraire, le mot clé basé sur les expressions régulières LogLevel déduit de LogMessage. Cette inférence peut entraîner des classifications incorrectes. LogLevelest un champ de chaîne avec une valeur telle que CRITICAL, , ERRORWARNING, 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, imageID, imageRepo et imageTag.

³ 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 Hubs 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 code JSON est incorrect, ces messages de journal sont 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 pour un cluster à l’aide du profil de journal du cluster ou de ConfigMap. Si les deux paramètres sont activés, ConfigMap est prioritaire. La ContainerLog table est utilisée uniquement lorsque les deux sont explicitement définis sur off.

Important

Le paramètre ContainerLogV2 ne contrôle pas si les données sont collectées ou non. Elle spécifie uniquement la table à laquelle les données sont envoyées lorsqu’elles sont collectées.

Avant d’activer le schéma ContainerLogV2 , évaluez si vous disposez de règles d’alerte qui reposent sur la table ContainerLog . Mettez à jour toutes ces alertes pour utiliser la nouvelle table. Exécutez la requête Azure Resource Graph suivante pour rechercher des règles d’alerte qui référencent 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 étend le schéma ContainerLogV2 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 améliorent la visibilité de vos charges de travail.

Remarque

Les métadonnées et journaux Kubernetes filtrant le tableau de bord Grafana ne prennent pas actuellement en charge les journaux de base.

Fonctionnalités

• Schéma ContainerLogV2 amélioré Lorsque vous activez les métadonnées Kubernetes, la table ContainerLogV2 inclut une nouvelle colonne appelée KubernetesMetadata. Cette colonne facilite la résolution des problèmes à l’aide de requêtes de journal simples et supprime la nécessité d’effectuer des jointures avec d’autres tables. Les champs de cette colonne incluent podLabels, podAnnotations, podUid, image, imageID, imageRepo et imageTag. Pour activer cette fonctionnalité, consultez Activer les métadonnées Kubernetes.

• Niveau de journal Cette fonctionnalité ajoute une LogLevel colonne avec ContainerLogV2 les valeurs CRITICALpossibles , , ERRORWARNINGINFO, DEBUG, , TRACEou .UNKNOWN Cette colonne vous aide à évaluer l’intégrité de l’application en fonction du niveau de gravité. Le tableau de bord Grafana visualise les tendances des niveaux de journalisation au fil du temps pour identifier rapidement les ressources affectées.

• Tableau de bord Grafana pour la visualisation Le tableau de bord Grafana fournit une visualisation codée en couleur du niveau de journalisation et des insights sur le volume de journaux, le taux de journalisation et les enregistrements de journal. Le tableau de bord décompose les données par ordinateur, pod et conteneur pour la résolution des problèmes ciblés. Pour installer le tableau de bord, consultez Le tableau de bord Installer 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, dans votre espace de travail Log Analytics, tous les journaux de conteneur de l’espace de noms système sont exclus pour réduire le coût des données. 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 collection de métadonnées Kubernetes nécessite l’authentification d’identité managée et ContainerLogV2.

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 KubernetesMetadata colonne apparaît dans n’importe quelle requête de journal pour la ContainerLogV2 table, comme illustré dans la capture d’écran suivante.

Installer le tableau de bord Grafana

Important

Si vous avez activé Grafana à l’aide des instructions de Enable monitoring 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 qui contient des données de journal. Consultez Comment modifier les autorisations d'accès à Azure Monitor pour obtenir des conseils sur l'octroi à votre instance Grafana du rôle de lecteur de surveillance pour votre espace de travail Log Analytics.

Importez le tableau de bord à partir de la galerie Grafana dans Tableau de bord ContainerLogV2. Ouvrez le tableau de bord et sélectionnez des valeurs pour DataSource, Subscription, ResourceGroup, Cluster, Namespace et Labels.

Remarque

Lorsque vous chargez initialement le tableau de bord Grafana, vous pouvez rencontrer des erreurs, car les variables ne sont pas encore sélectionnées. Pour éviter cela périodique, enregistrez le tableau de bord après avoir sélectionné un ensemble de variables afin qu’il devienne la valeur par défaut lors de la première ouverture.

Journalisation multiligne

La journalisation multiligne regroupe les journaux de conteneur divisés précédemment et les envoie sous forme d’entrées uniques à la ContainerLogV2 table. Activez la journalisation multiligne à l’aide de ConfigMap, comme décrit dans Configurer la collecte de journaux de conteneur avec 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 permet uniquement d’effectuer des suivis de pile d’exceptions à partir des conteneurs à l’aide de Java, de Python, de .NET et de 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.
• La journalisation multiligne n’est pas prise en charge pour les traces de pile d’exceptions Python avec fine-grained-error-locations-in-tracebacks. Pour que la journalisation multiligne fonctionne, vous devez désactiver cette fonctionnalité, comme décrit dans Python documentation.
• Par défaut, le runtime de conteneur tronque les lignes de journal à 16 Ko. Lorsque vous activez la journalisation multiligne, ContainerLogV2 prend en charge les lignes de journalisation jusqu’à 64 Ko.

Exemples

La journalisation multiligne des traces d’exceptions de Go est désactivée

La journalisation multiligne des traces d’exceptions de Go est activée

Journalisation multiligne de trace de pile de Java activée

Journalisation multiligne de trace de pile de Python activée

Étapes suivantes

• Configurez les journaux de base pour ContainerLogV2.
• Découvrez comment interroger les données dans ContainerLogV2.