Filtrer la collecte de journaux dans Container Insights
Cet article décrit les différentes options de filtrage disponibles dans Container Insights. Les clusters Kubernetes génèrent une grande quantité de données collectées par Container Insights. Étant donné que vous êtes facturé pour l’ingestion et la rétention de ces données, vous pouvez réduire considérablement vos coûts de surveillance en filtrant les données dont vous n’avez pas besoin.
Important
Cet article décrit différentes options de filtrage qui vous obligent à modifier la DCR ou le ConfigMap pour un cluster surveillé. Pour plus d’informations sur l’exécution de cette configuration, consultez Configurer la collecte de journaux dans Container Insights.
Filtrer les journaux de conteneur
Les journaux de conteneur sont les journaux stderr et stdout générés par des conteneurs dans votre cluster Kubernetes. Ces journaux sont stockés dans la table ContainerLogV2 dans votre espace de travail Log Analytics. Par défaut, tous les journaux de conteneur sont collectés, mais vous pouvez filtrer et exclure les journaux de certains espaces de noms spécifiques ou désactiver entièrement la collecte des journaux de conteneur.
À l’aide de la règle de collecte de données (DCR), vous pouvez activer ou désactiver les journaux stdout et stderr, et filtrer des espaces de noms spécifiques de chacun d’eux. Les paramètres de filtrage des journaux de conteneur et d’espace de noms sont inclus dans les présélections de coût configurées dans le portail Azure, et vous pouvez définir ces valeurs individuellement à l’aide des autres méthodes de configuration DCR.
À l’aide de ConfigMap, vous pouvez configurer la collecte des journaux stderr
et stdout
séparément pour le cluster. Vous pouvez donc choisir d’activer l’un et non l’autre.
L’exemple suivant montre les paramètres ConfigMap pour collecter stdout et stderr à l’exclusion des espaces de noms kube-system
et gatekeeper-system
.
[log_collection_settings]
[log_collection_settings.stdout]
enabled = true
exclude_namespaces = ["kube-system","gatekeeper-system"]
[log_collection_settings.stderr]
enabled = true
exclude_namespaces = ["kube-system","gatekeeper-system"]
[log_collection_settings.enrich_container_logs]
enabled = true
Filtrage des journaux de plateforme (espaces de noms de système Kubernetes)
Par défaut, les journaux de conteneur de l’espace de noms système sont exclus de la collecte afin de réduire au minimum le coût de Log Analytics. Les journaux de conteneur des conteneurs système peuvent être critiques dans des scénarios de résolution des problèmes spécifiques. Cette fonctionnalité est limitée aux espaces de noms système suivants : kube-system
, gatekeeper-system
, calico-system
, azure-arc
, kube-public
et kube-node-lease
.
Activez les journaux de plateforme à l’aide de ConfigMap avec le paramètre collect_system_pod_logs
. Vous devez également vérifier que l’espace de noms système n’est pas dans le paramètre exclude_namespaces
.
L’exemple suivant montre les paramètres ConfigMap pour collecter les journaux stdout et stderr du conteneur coredns
dans l’espace de noms kube-system
.
[log_collection_settings]
[log_collection_settings.stdout]
enabled = true
exclude_namespaces = ["gatekeeper-system"]
collect_system_pod_logs = ["kube-system:coredns"]
[log_collection_settings.stderr]
enabled = true
exclude_namespaces = ["kube-system","gatekeeper-system"]
collect_system_pod_logs = ["kube-system:coredns"]
Filtrage basé sur des annotations pour les charges de travail
Le filtrage basé sur les annotations vous permet d’exclure la collecte de journaux pour certains pods et conteneurs en annotant le pod. Cela peut réduire considérablement les coûts d’ingestion des journaux, et vous permettre de vous concentrer sur les informations pertinentes sans avoir à éliminer le bruit.
Activez le filtrage basé sur les annotations en utilisant ConfigMap avec les paramètres suivants.
[log_collection_settings.filter_using_annotations]
enabled = true
Vous devez également ajouter les annotations requises sur votre spécification des pods de charge de travail. Le tableau suivant met en évidence différentes annotations de pod possibles.
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 une 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
Filtrer les variables d’environnement
Activez la collecte de variables d’environnement sur tous les pods et nœuds du cluster en utilisant ConfigMap avec les paramètres suivants.
[log_collection_settings.env_var]
enabled = true
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.
Impact sur les visualisations et les alertes
Si vous avez des alertes ou des classeurs personnalisés utilisant des données Container Insights, la modification de vos paramètres de collecte de données peut entraîner une dégradation de ces expériences. Si vous excluez des espaces de noms ou réduisez la fréquence de collecte de données, évaluez vos alertes, tableaux de bord et classeurs existants à l’aide de ces données.
Pour rechercher les alertes qui font référence à ces tables, 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 "Perf" or properties contains "InsightsMetrics" or properties contains "ContainerInventory" or properties contains "ContainerNodeInventory" or properties contains "KubeNodeInventory" or properties contains"KubePodInventory" or properties contains "KubePVInventory" or properties contains "KubeServices" or properties contains "KubeEvents"
| project id,name,type,properties,enabled,severity,subscriptionId
| order by tolower(name) asc
Étapes suivantes
- Pour ajouter des transformations à la DCR qui filtreront davantage les données en fonction de critères détaillés, consultez Transformations de données dans Container Insights.