Comprendre les coûts de surveillance pour Container Insights

Cet article fournit des conseils de tarification associés à Insights de conteneur, afin de vous aider à comprendre comment :

• Mesurer les coûts après l’activation de Container Insights pour un ou plusieurs conteneurs.
• Contrôler la collection des données et réduire les coûts.

Conseil

Pour connaître les stratégies de réduction de vos coûts Azure Monitor, consultez Optimisation des coûts et Azure Monitor.

Le modèle de tarification Azure Monitor repose principalement sur la quantité de données ingérées par jour dans votre espace de travail Log Analytics (en gigaoctets). De ce fait, le coût d’un espace de travail Log Analytics n’est pas seulement fonction du volume des données collectées, mais du fait qu’il dépend aussi du plan sélectionné et de la durée de stockage des données générées par vos clusters.

Remarque

Consultez Estimer les coûts d’Azure Monitor pour estimer les coûts de Container Insights avant de l’activer.

Les types de données suivants, collectés à partir d’un cluster Kubernetes avec Insights de conteneur, influencent le coût et peuvent être personnalisés en fonction de votre utilisation :

• Perf, Inventory, InsightsMetrics et KubeEvents peuvent être contrôlés via des paramètres d’optimisation des coûts
• Journaux stdout et stderr de chaque conteneur analysé dans chaque espace de noms Kubernetes du cluster via l’agent ConfigMap
• Variables d’environnement de chaque conteneur analysé dans le cluster
• Tâches/pods Kubernetes terminés dans le cluster qui ne nécessitent pas d’analyse
• Activer le scraping des métriques Prometheus
• Collection des journaux de ressources des nœuds Kubernetes principaux de votre cluster AKS, pour l’analyse des données des journaux générés par les principaux composants (comme kube-apiserver et kube-controller-manager).

Contrôle de l’ingestion pour réduire les coûts

Envisageons un scénario dans lequel les différentes divisions de l’organisation partagent l’infrastructure Kubernetes et un espace de travail Log Analytics. Chaque division est séparée des autres par un espace de noms Kubernetes. Vous pouvez visualiser la quantité de données ingérées dans chaque espace de travail en utilisant le runbook Utilisation de données. Le runbook est disponible à partir de l'onglet Rapports.

Ce classeur permet de visualiser la source de vos données sans avoir à créer votre propre bibliothèque de requêtes à partir des informations de notre documentation. Dans ce classeur, vous pouvez afficher des graphiques qui présentent des données facturables telles que :

• Total des données facturables ingérées par chaque solution, en Go.
• Données facturables ingérées par chaque journal de conteneur (journal des applications).
• Données des journaux de conteneurs facturables ingérées par chaque espace de noms Kubernetes.
• Données des journaux de conteneurs facturables ingérées, par nom de cluster.
• Données des journaux de conteneurs facturables ingérées par l’entrée de source de journal.
• Données de diagnostic facturables ingérées, par journal de diagnostic de nœud principal.

Pour en savoir plus sur la gestion des droits et des autorisations d’accès aux classeurs, voir Contrôle d’accès.

Détermination de la cause racine de l’ingestion de données

Les données Container Insights se composent principalement de compteurs de métriques (Perf, Inventory, InsightsMetrics et métriques personnalisées) et de journaux (ContainerLog). En fonction de l’utilisation et de la taille de votre cluster, vous pouvez avoir des exigences et des besoins de supervision différents.

En accédant à la section Par table du classeur Utilisation des données, vous pouvez voir la répartition des tailles de table pour Container Insights.

Si la majorité de vos données provient de l’une des tables suivantes :

• Perf
• InsightsMetrics
• ContainerInventory
• ContainerNodeInventory
• KubeNodeInventory
• KubePodInventory
• KubePVInventory
• KubeServices
• KubeEvents

Vous pouvez ajuster votre ingestion à l’aide des paramètres d’optimisation des coûts et/ou effectuer une migration vers le module complémentaire des métriques Prometheus

Sinon, la majorité de vos données appartiennent à la table ContainerLog. et vous pouvez suivre les étapes ci-dessous pour réduire vos coûts ContainerLog.

Réduction de vos coûts ContainerLog

Une fois que vous avez terminé votre analyse pour déterminer quelles sources génèrent les données qui dépassent vos exigences, vous pouvez reconfigurer la collecte des données. Pour plus d’informations sur la configuration de la collecte des variables stdout, stderr et environnementales, consultez Configurer les paramètres de collecte de données de l’agent.

Les exemples suivants montrent les changements que vous pouvez appliquer à votre cluster en modifiant le fichier ConfigMap pour aider à contrôler les coûts.

1. Désactivez les journaux stdout sur tous les espaces de noms du cluster en modifiant le code suivant dans le fichier ConfigMap du service Azure Insights de conteneur qui tire les métriques :

   [log_collection_settings]       
      [log_collection_settings.stdout]          
         enabled = false
   

2. Désactivez la collecte des journaux stderr à partir de votre espace de noms de développement. par exemple dev-test. Continuez à collecter les journaux stderr à partir d’autres espaces de noms, prod tels que et default, en modifiant le code suivant dans le fichier ConfigMap :

   Notes

   La collection de journaux de kube-system est désactivée par défaut. Le paramètre par défaut est conservé. L’ajout de l’espace de noms dev-test à la liste des espaces de noms d’exclusion est appliqué à la collection de journaux stderr.

   [log_collection_settings.stderr]          
      enabled = true          
         exclude_namespaces = ["kube-system", "dev-test"]
   

3. Désactivez la collection de variables d’environnement sur l’ensemble du cluster en modifiant le code suivant dans le fichier ConfigMap. Cette modification s’applique à tous les conteneurs de chaque espace de noms Kubernetes.

   [log_collection_settings.env_var]
       enabled = false
   

4. Pour nettoyer les taches terminées, définissez la stratégie de nettoyage dans le yaml de votre définition de tâche. Voici un exemple de définition de tâche avec une stratégie de nettoyage. Pour plus d’informations, reportez-vous à la documentation Kubernetes.

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: pi-with-ttl
   spec:
     ttlSecondsAfterFinished: 100
   

Après avoir appliqué une ou plusieurs de ces modifications à votre fichier ConfigMaps, appliquez-le à votre cluster avec la commande kubectl apply -f <config3. map_yaml_file.yaml>. Par exemple, exécutez la commande kubectl apply -f container-azm-ms-agentconfig.yaml afin d’ouvrir le fichier dans votre éditeur, puis modifiez-le et fermez-le.

Configurer les journaux de base

Vous pouvez économiser sur les coûts d’ingestion des données ContainerLog dans l’espace de travail Log Analytics que vous utilisez principalement à des fins de débogage, de résolution des problèmes et d’audit en tant que Journaux de base. Pour plus d’informations, notamment les limitations des journaux d’activité basiques, consultez Configurer les journaux d’activité basiques dans Azure Monitor. ContainerLogV2 est la version configurée des journaux de base que Container Insights utilise. ContainerLogV2 inclut des enregistrements de journal de type texte détaillés.

Vous devez être sur le schéma ContainerLogV2 pour configurer les journaux de base. Pour plus d’informations, consultez Activer le schéma ContainerLogV2 (préversion).

Capture de métriques Prometheus

Remarque

Cette section décrit la collecte de métriques Prometheus dans votre espace de travail Log Analytics. Ces informations ne s’appliquent pas si vous utilisez Prometheus managé pour scraper vos métriques Prometheus.

Si vous utilisez la collecte de métriques Prometheus dans votre espace de travail Log Analytics, veillez à limiter le nombre de métriques que vous collectez à partir de votre cluster :

• Assurez-vous que la fréquence de scraping est définie de manière optimale. La valeur par défaut est de 60 secondes. Vous pouvez faire monter la fréquence à 15 secondes, mais vous devez vous assurer que les métriques obtenues via ce scraping sont publiées à cette fréquence. Dans le cas contraire, de nombreuses métriques en double seront scrapées et envoyées à votre espace de travail Log Analytics, selon des intervalles qui augmenteront les coûts d’ingestion de données et de rétention, mais qui présenteront moins de valeur.
• Insights de conteneur prend en charge les listes d’exclusions et d’inclusions par nom de métrique. Par exemple, si vous scrapez des métriques kubedns dans votre cluster, des centaines d’entre elles peuvent être scrapées par défaut. Mais vous êtes probablement intéressé uniquement par un sous-ensemble des métriques. Confirmez que vous avez spécifié une liste de métriques à scraper, ou excluez-en d’autres et conservez-en quelques-unes pour les enregistrer sur le volume d’ingestion de données. Vous pouvez aisément activer le scraping et éviter d’utiliser un grand nombre de ces métriques, qui ne feront qu’ajouter des frais à votre facture Log Analytics.
• Lors du scraping via des annotations de pods, appliquez un filtrage par espace de noms de manière à exclure le scraping des métriques de pods des espaces de noms que vous n’utilisez pas. L’espace de noms dev-test en est un exemple.

Données collectées à partir des clusters Kubernetes

Données métriques

Container Insights comprend un ensemble prédéfini de métriques et d’éléments d’inventaire collectés, qui sont écrits sous forme de données de journaux dans votre espace de travail Log Analytics. Toutes les métriques du tableau suivant sont collectées toutes les minutes.

Type	Mesures
Métriques de nœud	cpuUsageNanoCores cpuCapacityNanoCores cpuAllocatableNanoCores memoryRssBytes memoryWorkingSetBytes memoryCapacityBytes memoryAllocatableBytes restartTimeEpoch used (disque) free (disque) used_percent (disque) io_time (diskio) writes (diskio) reads (diskio) write_bytes (diskio) write_time (diskio) iops_in_progress (diskio) read_bytes (diskio) read_time (diskio) err_in (net) err_out (net) bytes_recv (net) bytes_sent (net) Kubelet_docker_operations (kubelet)
Métriques des conteneurs	cpuUsageNanoCores cpuRequestNanoCores cpuLimitNanoCores memoryRssBytes memoryWorkingSetBytes memoryRequestBytes memoryLimitBytes restartTimeEpoch

Inventaire du cluster

La liste suivante répertorie les données d’inventaire du cluster collectées par défaut :

• KubePodInventory : 1 par pod par minute
• KubeNodeInventory : 1 par nœud et par minute
• KubeServices : 1 par service et par minute
• ContainerInventory : 1 par conteneur et par minute

Étapes suivantes

Pour savoir comment interpréter les coûts qui sont susceptibles d’être basés sur des modèles d’utilisation récents des données collectées avec Container Insights, consultez Analyser l’utilisation dans l’espace de travail Log Analytics.