Configurer la collecte de données dans Container Insights à l’aide de ConfigMap

  • Article

Cet article explique comment configurer la collecte de données dans Container Insights à l’aide de ConfigMap. ConfigMaps sont un mécanisme Kubernetes qui vous permet de stocker des données non confidentielles telles que des variables de fichier de configuration ou d’environnement.

ConfigMap est principalement utilisé pour configurer la collecte de données des journaux de conteneur et des variables d’environnement du cluster. Vous pouvez configurer individuellement les journaux stdout et stderr et activer également la journalisation multiligne. L Configuration spécifique que vous pouvez effectuer avec ConfigMap inclut :

  • Activer/désactiver et filtrer l’espace de noms pour les journaux stdout et stderr
  • Activer/désactiver la collecte de variables d’environnement pour le cluster
  • Filtrer pour les événements Kube normaux
  • Sélectionner le schéma de journal
  • Activer/désactiver la journalisation multiligne
  • Ignorer les paramètres du proxy

Important

La configuration complète de la collecte de données dans Container Insights peut nécessiter la modification de ConfigMap et de la règle de collecte de données (DCR) pour le cluster, car chaque méthode autorise la configuration d’un ensemble de paramètres différent.

Consultez Configurer la collecte de données dans Container Insights à l’aide d’une règle de collecte de données pour obtenir la liste des paramètres et le processus de configuration de la collecte de données à l’aide de la DCR.

Prérequis

  • ConfigMap est une liste globale et il ne peut y avoir qu’un seul ConfigMap appliqué à l’agent pour Container Insights. L’application d’un autre ConfigMap remplace les paramètres de collection ConfigMap précédents.
  • La version minimale de l’agent prise en charge pour collecter des variables stdout, stderr et d’environnement à partir de charges de travail de conteneur est ciprod06142019 ou une version ultérieure. Pour vérifier la version de votre agent, sous l’onglet Nœud, sélectionnez un nœud. Dans le volet Propriétés, notez la valeur de la propriété Balise d’image de l’agent. Pour plus d’informations sur les versions de l’agent et le contenu de chaque version, consultez les notes de publication de l’agent.

Configurer et déployer ConfigMap

Utilisez la procédure suivante pour configurer et déployer votre fichier de configuration ConfigMap sur votre cluster :

  1. Téléchargez le fichier YAML configMap du modèle et ouvrez-le dans un éditeur. Si vous avez déjà un fichier ConfigMap, vous pouvez l’utiliser.

  2. Modifiez le fichier YAML ConfigMap avec vos personnalisations à l’aide des paramètres décrits dans paramètres de collecte de données

  3. Créez une ConfigMap en exécutant la commande kubectl suivante :

    kubectl apply -f <configmap_yaml_file.yaml>

    Exemple :

    kubectl apply -f container-azm-ms-agentconfig.yaml

    Quelques minutes peuvent être nécessaires pour que la modification de configuration soit effective. Alors tous les pods de l’agent Azure Monitor dans le cluster vont redémarrer. Le redémarrage s’effectue de façon progressive pour tous les pods de l’agent Azure Monitor. Tous les pods ne redémarrent pas en même temps. Une fois les redémarrages terminés, vous recevrez un message similaire au résultat suivant :

    configmap "container-azm-ms-agentconfig" created`.

Paramètres de collecte de données

Le tableau suivant décrit les paramètres que vous pouvez configurer pour contrôler la collecte de données.

Setting Type de données Valeur Description
schema-version Chaîne (respecte la casse) v1 Utilisé par l’agent lors de l’analyse de ce ConfigMap. Actuellement, la version prise en charge est v1. Modifier cette valeur n’est pas pris en charge et est rejeté lors de l’évaluation de l’élément ConfigMap.
config-version Chaîne Vous permet de suivre la version de ce fichier de configuration dans votre système/référentiel de contrôle de code source. Le nombre maximal de caractères autorisé est 10 et tous les autres caractères sont tronqués.
[log_collection_settings]
[stdout] enabled Boolean true
false		 Contrôle si la collecte de journaux de conteneur stdout est activée. Lorsqu’ils sont définis sur true et qu’aucun espace de noms n’est exclu pour la collecte de journaux stdout, les journaux stdout sont collectés à partir de tous les conteneurs sur tous les pods et nœuds du cluster. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut esttrue.
[stdout] exclude_namespaces Chaîne Tableau séparé par des virgules Tableau d’espaces de noms Kubernetes pour lesquels aucun journal stdout n’est collecté. Ce paramètre est effectif uniquement si enabled est défini sur true. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut est
["kube-system","gatekeeper-system"].
[stderr] enabled Boolean true
false		 Contrôle si la collecte de journaux de conteneur stderr est activée. Lorsqu’ils sont définis sur true et qu’aucun espace de noms n’est exclu pour la collecte de journaux stderr, les journaux stderr sont collectés à partir de tous les conteneurs sur tous les pods et nœuds du cluster. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut esttrue.
[stderr] exclude_namespaces Chaîne Tableau séparé par des virgules Tableau d’espaces de noms Kubernetes pour lesquels aucun journal stderr n’est collecté. Ce paramètre est effectif uniquement si enabled est défini sur true. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut est
["kube-system","gatekeeper-system"].
[env_var] enabled Boolean true
false		 Ce paramètre contrôle la collecte de variables d’environnement sur tous les pods et nœuds du cluster. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut esttrue. Si la collection de variables d’environnement est globalement activée, vous pouvez la désactiver pour un conteneur spécifique en définissant la variable d’environnement AZMON_COLLECT_ENV sur False avec un paramètre Dockerfile ou dans le fichier de configuration du pod sous la section env:. Si la collecte de variables d’environnement est globalement désactivée, vous ne pouvez pas activer la collecte pour un conteneur spécifique. La seule substitution applicable au niveau du conteneur consiste à désactiver la collecte lorsqu’elle est déjà activée globalement.
[enrich_container_logs] enabled Boolean true
false		 Contrôle l’enrichissement du journal des conteneurs pour remplir les valeurs de propriété Name et Image pour chaque enregistrement de journal écrit dans la table ContainerLogV2 ou ContainerLog pour tous les journaux de conteneur du cluster. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut estfalse.
[collect_all_kube_events] enabled Boolean true
false		 Contrôle si les événements Kube de tous les types sont collectés. Par défaut, les événements Kube de type Normal ne sont pas collectés. Lorsque ce paramètre est true, les événements normal ne sont plus filtrés et tous les événements sont collectés. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut estfalse.
[schema] containerlog_schema_version Chaîne (respecte la casse) v2
v1		 Définit le format d’ingestion du journal. Si v2, la table ContainerLogV2 est utilisée. Si v1, la table ContainerLog est utilisée (cette table a été déconseillée). Pour les clusters activant Container Insights à l’aide d’Azure CLI version 2.54.0 ou ultérieure, le paramètre par défaut est v2. Pour plus d’informations, consultez schéma de journal Container Insights .
[enable_multiline_logs] enabled Boolean true
false		 Contrôle si les journaux de conteneurs multilignes sont activés. Pour plus d’informations, consultez journalisation multiligne dans Container Insights. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut estfalse. Cela nécessite que le paramètre schema soit v2.
[metric_collection_settings]
[collect_kube_system_pv_metrics] enabled Boolean true
false		 Autorise la collecte des métriques d’utilisation de volume persistant (PV) dans l’espace de noms kube-system. Par défaut, les métriques d’utilisation des volumes persistants ayant des revendications de volume persistant dans l’espace de noms kube-system ne sont pas collectées. Lorsque ce paramètre est défini sur true, les métriques d’utilisation de volume persistant sont collectées pour tous les espaces de noms. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut estfalse.
[agent_settings]
[proxy_config] ignore_proxy_settings Boolean true
false		 Quand true, les paramètres du proxy sont ignorés. Pour les environnements Kubernetes compatibles AKS et Arc, si votre cluster est configuré avec le proxy de transfert, les paramètres de proxy sont automatiquement appliqués et utilisés pour l’agent. Pour certaines configurations, comme avec AMPLS + Proxy, vous souhaiterez peut-être que la configuration du proxy soit ignorée. Si elle n’est pas spécifiée dans la ConfigMap, la valeur par défaut estfalse.

Vérifier la configuration

Pour vérifier que la configuration a été correctement appliquée à un cluster, utilisez la commande suivante pour passer en revue les journaux d’activité d’un pod d’agent.

kubectl logs ama-logs-fdf58 -n kube-system

S’il existe des erreurs de configuration au niveau des pods de l’agent Azure Monitor, la sortie affichera des erreurs similaires à celles-ci :

***************Start Config Processing******************** 
config::unsupported/missing config schema version - 'v21' , using defaults

Les erreurs liées à l’application de modifications de configuration sont également disponibles pour consultation. Les options suivantes sont disponibles pour effectuer un dépannage supplémentaire des modifications de configuration :

  • À partir d’un journal des pods d’agent à l’aide de la même commande kubectl logs.

  • À partir de journaux dynamiques. Les journaux dynamiques affichent des erreurs similaires à l’exemple suivant :

    config::error::Exception while parsing config map for log collection/env variable settings: \nparse error on value \"$\" ($end), using defaults, please check config map for errors

  • À partir de la table KubeMonAgentEvents dans votre espace de travail Log Analytics. Les données sont envoyées toutes les heures avec la gravité de l’erreur pour les erreurs de configuration. S’il n’y a pas d’erreur, l’entrée de la table contient des données avec des informations de gravité ne signalant aucune erreur. La propriété Balises contient plus d’informations sur le pod et l’ID de conteneur où l’erreur s’est produite, ainsi que sur la première occurrence, la dernière occurrence et le nombre d’occurrences au cours de la dernière heure.

Vérifier la version du schéma

Les versions de schéma de configuration prises en charge sont fournies sous forme d’annotation de pod (schema-versions) sur le pod de l’agent Azure Monitor. Vous pouvez les voir avec la commande kubectl suivante.

kubectl describe pod ama-logs-fdf58 -n=kube-system.

Une sortie similaire à l’exemple suivant s’affiche avec les versions de schéma d’annotation :

    Name:           ama-logs-fdf58
    Namespace:      kube-system
    Node:           aks-agentpool-95673144-0/10.240.0.4
    Start Time:     Mon, 10 Jun 2019 15:01:03 -0700
    Labels:         controller-revision-hash=589cc7785d
                    dsName=ama-logs-ds
                    pod-template-generation=1
    Annotations:    agentVersion=1.10.0.1
                  dockerProviderVersion=5.0.0-0
                    schema-versions=v1

Forum aux questions

Comment puis-je activer la collecte des journaux pour les conteneurs de l'espace de noms kube-system via Helm ?

Par défaut, la collecte des journaux des conteneurs de l'espace de noms kube-system est désactivée. Vous pouvez activer la collecte des journaux en définissant une variable d’environnement sur l’agent Azure Monitor. Consultez la page GitHub Container Insights.

Étapes suivantes