Surveillance de Containerd

Informations de support

Pour vous assurer que le capteur Containerd est compatible avec votre configuration actuelle, consultez les sections suivantes de la documentation d'assistance :

Systèmes d'exploitation pris en charge

Modifier en ligne

Les systèmes d'exploitation pris en charge par le capteur Containerd correspondent aux exigences des agents hôtes; vous pouvez les vérifier dans la section « Systèmes d'exploitation pris en charge » de chaque agent hôte, par exemple « Systèmes d'exploitation pris en charge pour Unix ».

Versions prises en charge et politique d'assistance

Modifier en ligne

Le capteur prend en charge les versions suivantes de Containerd :

1.6.x
1.7.x
2.0.x

Le tableau suivant présente la dernière version prise en charge et la politique d'assistance :


Technologie	Politique de support	Dernière version technologique	Dernière version prise en charge
Containerd	45 jours	2.3.2	2.3.1

Pour plus d'informations sur la politique d'assistance, consultez la section « Stratégie d'assistance pour les capteurs ».

Environnements pris en charge

Modifier en ligne

Si l'environnement utilise des conteneurs Docker ou Garden, le capteur Containerd est automatiquement désactivé afin d'éviter que plusieurs capteurs ne surveillent inutilement les mêmes conteneurs.

Conteneurs pris en charge

Modifier en ligne

Tous les conteneurs qui exécutent l'environnement d'exécution de conteneur Containerd sont pris en charge, à l'exception des conteneurs de pause.

Le conteneur de pause est un conteneur qui contient l'espace de nom du réseau pour le pod. Kubernetes crée des conteneurs de pause pour acquérir l'adresse IP de chaque pod et configurer l'espace de nom réseau pour tous les autres conteneurs qui rejoignent ce pod.

Les conteneurs de pause ne sont pas pris en charge pour les raisons suivantes:

La surveillance des conteneurs de pause ne fournit pas beaucoup d'informations au niveau de l'infrastructure car ils agissent en tant que conteneurs auxiliaires sidecar.
Lorsque les conteneurs en pause sont pris en compte, cela double le nombre de conteneurs surveillés dans un environnement et augmente donc les coûts liés à la surveillance d' Instana.

Plates-formes d'orchestration de conteneurs prises en charge

Modifier en ligne

La plupart des distributions d' Kubernetes, par exemple Kubernetes (version en amont) avec kubeadm, GKE, EKS et AKS, utilisent Containerd comme moteur d'exécution de conteneurs par défaut. Ce n'est toutefois pas le cas pour OpenShift,, qui utilise le moteur de conteneurs CRI-O. Pour les clusters d' Kubernetes, tels que OpenShift,, Instana prend en charge la collecte de métriques de conteneurs pour CRI-O via le capteur CRIO. La collecte des journaux pour les conteneurs d' CRI-O s n'est pas directement prise en charge par le capteur CRIO; il est donc recommandé d'utiliser le collecteur OpenTelemetry pour collecter les journaux des conteneurs d' CRI-O s dans ces distributions Kubernetes qui utilisent CRI-O comme moteur d'exécution de conteneurs.

Configuration

Modifier en ligne

Le capteur Containerd interroge les métadonnées des conteneurs, notamment les étiquettes d' Kubernetes, qui s'affichent dans l'onglet « Étiquettes d' Kubernetes » de l'interface utilisateur de Instana. Il utilise l'interface CRI ( API ) pour les environnements d' Kubernetes s pris en charge.

Un client CRI ( API ) natif peut être activé dans Kubernetes en définissant la variable d'environnement INSTANA_USE_CONTAINERD_CRI_CLIENT (valeur par défaut : true). Lorsque cette variable est définie sur true, les métadonnées du conteneur sont collectées via le socket Containerd, généralement situé à l'adresse /var/run/containerd/containerd.sock, à moins que d'autres sockets ne soient spécifiés dans la configuration du capteur.

Remarque : lorsque INSTANA_USE_CONTAINERD_CRI_CLIENT l'indicateur est défini sur « false » ou que le cluster Kubernetes ne prend pas en charge l'interface CRI- API, le capteur utilise par défaut le crictl binaire. Le fichier crictl binaire n'est pas fourni avec l'agent Instana. Vous devez effectuer l'installation sur le serveur hôte sur lequel l'agent hôte d' Instana s est installé et mis à la disposition du conteneur d'agent. Une fois l'installation terminée, ajoutez le chemin d'accès au fichier crictl binaire à la variable $PATH d'environnement de l'utilisateur sous lequel l'agent hôte s'exécute. Si l'outil crictl en ligne de commande n'est pas installé, la collecte des indicateurs de performance du capteur Containerd concernant l'utilisation du processeur et de la mémoire peut fonctionner, mais les étiquettes « Kubernetes » associées au conteneur ne peuvent pas s'afficher dans l'onglet « Kubernetes Labels» de l'interface utilisateur d' Instana. De plus, la collecte des journaux des conteneurs reste désactivée. Pour plus d'informations sur la collecte des journaux, consultez la section « Configuration du capteur Containerd-Log ».

Configuration du capteur Containerd

Modifier en ligne

Vous pouvez configurer le capteur Containerd dans le fichier de configuration de l'agent, comme le montre l'exemple suivant :

  com.instana.plugin.containerd:
    enabled: true
    poll_rate: 10
    unixSockets:
      - '/path/to/containerd.sock'


Paramètre	Description	Obligatoire ou facultatif	Plage de valeurs
`com.instana.plugin.containerd.enabled`	Indicateur d'activation du capteur Containerd.	Facultatif	`false` ou`true`. Valeur par défaut :`true`
`poll_rate`	Définit la fréquence d'interrogation du plug-in en secondes.	Facultatif	De 1 à 3 600. Valeur par défaut : 10
`com.instana.plugin.containerd.unixSockets`	Disponible depuis : capteur Containerd 1.0.30. Liste des chemins d'accès complets vers `containerd.sock` les fichiers. Le capteur dispose d'une fonctionnalité de détection automatique des fichiers de configuration qui recherche le `containerd.sock` fichier dans les `/run/` répertoires `/var/run/` et. Si un autre emplacement est configuré pour le socket, le chemin qualifié complet doit être ajouté.	Facultatif	Liste des chemins d'accès complets aux fichiers.

Configuration de la fréquence d'interrogation

Modifier en ligne

Remarque : Instana Le capteur Containerd 1.0.46 et les versions ultérieures permettent de configurer la fréquence d'interrogation afin de réduire le volume de données ingérées. Cette fonctionnalité est prise en charge sur le backend Instana auto-hébergé à partir de la version 311.

Vous pouvez définir la fréquence à laquelle l' Instana interroge Containerd pour collecter des données et des métriques en utilisant le poll_rate paramètre dans le fichier de configuration.yaml l'agent, comme le montre l'exemple suivant :

com.instana.plugin.containerd:
  poll_rate: 10

Activation de la collecte des métriques

Modifier en ligne

Le capteur Containerd, à partir de ctr la version 1.2.0, peut collecter automatiquement des métriques à l'aide de la ctr task metrics commande. Dans ce cas, vous n'avez pas besoin d'activer manuellement la collecte de métriques.

Le capteur Containerd avec les versions ctr1.2.0 et antérieures ne prend pas en charge la metrics commande. Si vous utilisez ctr1.2.0 ou une version antérieure, le capteur tentera d'interroger les métriques via le point de terminaison Prometheus. Pour activer le noeud final Prometheus , vous devez spécifier l'adresse "metrics" "127.0.0.1:1338" dans le fichier de configuration /etc/containerd/config.toml , puis redémarrer containerd.service.

[metrics]
  address = "127.0.0.1:1338"

Affichage des mesures

Modifier en ligne

Pour afficher les métriques, procédez comme suit:

Dans la barre latérale de l'interface utilisateur d' Instana, sélectionnez « Infrastructure ».
Cliquez sur un hôte qui possède un conteneur Containerd.

Vous pouvez voir un tableau de bord hôte avec toutes les métriques collectées et les processus surveillés.

Afficher les détails du conteneur

Modifier en ligne

Pour extraire les détails du conteneur, cliquez sur Obtenir des informations sur le conteneur.

Les informations suivantes s'affichent :

ID intra-conteneur
Image
Créé à
Mis à jour à
Espace de nom Containerd
Libellés

Métriques de performance

Modifier en ligne


Métrique	Description	Granularité
Utilisation de l'UC	Les métriques incluent l'utilisation totale de l'UC, l'utilisation de l'UC du noyau, l'utilisation de l'UC utilisateur et l'utilisation de l'UC normalisée.	10 secondes
Limitation d'UC	Durée de limitation et nombre	10 secondes
Utilisation de la mémoire	Les métriques incluent l'utilisation totale de la mémoire en octets, la taille de l'ensemble résident en octets, l'utilisation du cache en octets, l'utilisation totale de la mémoire en pourcentage et l'utilisation de la partie active en pourcentage.	10 secondes
Mémoire active	Quantité de mémoire anonyme et de mémoire cache active	10 secondes
Mémoire inactive	Quantité de mémoire anonyme et de mémoire cache inactive	10 secondes
E-S par bloc	Quantité de données, en octets, que le conteneur surveillé écrit et lit à partir de l'unité par bloc	10 secondes

Indicateurs de performance dérivés

Modifier en ligne

Vous pouvez consulter les indicateurs dérivés suivants dans l'interface utilisateur d' Instana :

Total UC normalisé
% d'utilisation de la mémoire
% d'utilisation de la mémoire active

Utilisation totale normalisée du processeur

Modifier en ligne

La métrique CPU Total Normalized correspond à l'utilisation de l'unité centrale normalisée du conteneur en pourcentage. La valeur peut être comprise entre 0% et 100%. La métrique est calculée à l'aide de la formule suivante: total_normalized_cpu_usage_percentage = cpu_total_usage / cpu_limit

La valeur cpu_limit dépend de la configuration du conteneur qui est déployé. La valeur de la métrique total_normalized_cpu_usage_percentage n'est pas connue si cpu_limit n'est pas spécifié dans la configuration du conteneur déployé.

Utilisation de la mémoire

Modifier en ligne

La métrique Memory Usage % correspond à l'utilisation de la mémoire en pourcentage, y compris la taille de l'ensemble résident et l'utilisation du cache du système de fichiers. La métrique est calculée à l'aide de la formule suivante: metric_usage_percentage = memory_used / memory_limit

La valeur de la métrique memory_limit dépend de la configuration du conteneur qui est déployé. La valeur de la métrique memory_used n'est pas connue si memory_limit n'est pas spécifié dans la configuration du conteneur déployé.

Utilisation de la mémoire active

Modifier en ligne

Memory Working Set Usage % correspond à l'utilisation de la mémoire en pourcentage, à l'exclusion du cache du système de fichiers. La métrique est calculée à l'aide de la formule suivante: memory_working_set_usage_percentage = (memory_used - total_inactive_file) / memory_limit

La valeur memory_limit dépend de la configuration de déploiement du conteneur. memory_working_set_usage_percentage n'est pas fourni lorsque memory_limit n'est pas spécifié dans la configuration de déploiement du conteneur.

Consulter les journaux de Containerd

Modifier en ligne

Remarque : pour pouvoir importer les journaux Containerd, votre licence doit inclure le module complémentaire de journalisation. Avant de continuer, consultez la section « Conditions relatives à la licence et aux droits » pour vérifier votre licence.

La collecte des journaux Containerd est prise en charge pour les versions 1.0.30 et ultérieures du capteur Containerd.

Remarque : si le client du capteur Containerd CRI- API est désactivé ou si crictl l'exécutable n'est pas accessible à l'agent, le capteur Containerd ne collecte pas les journaux. Pour plus d'informations, consultez la section « Configuration ».

Lorsque cette fonctionnalité est activée, le capteur Containerd ne collecte que les journaux des conteneurs enregistrés dans un fichier, car l' Instana, pour l'instant, ne prend en charge que le pilote de journalisation par défaut, qui enregistre les entrées de journal dans un fichier.

Par exemple, dans les déploiements Kubernetes , les journaux Containerd peuvent être écrits dans des fichiers du répertoire /var/log/pods/{namespace}_{podName}_{podUID}/{containerName} .

Vous pouvez consulter les journaux collectés en cliquant sur « Analytics > Logs » dans l'interface utilisateur d' Instana, puis filtrer les journaux à l'aide du filtre « Container Snapshot Id », qui permet de filtrer à la fois les messages de journal d' Docker et ceux de Containerd.

Configuration du capteur Containerd-Log

Modifier en ligne

Vous pouvez configurer le capteur Containerd-Log dans le fichier de configuration de l'agent, comme le montre l'exemple suivant, à l'aide de la logs section.

  com.instana.plugin.containerd:
    enabled: true
    poll_rate: 10
    logs:
      enabled: true
      sendInterval: 60
      maxBufferSize: 16777216
    unixSockets:
      - '/path/to/containerd.sock'

Les paramètres de configuration supplémentaires relatifs à la journalisation sont décrits dans le tableau suivant :


Paramètre	Description	Obligatoire ou facultatif	Plage de valeurs
`com.instana.plugin.containerd.logs.enabled`	Disponible depuis : capteur Containerd 1.0.30. Indicateur permettant d'activer la collecte des journaux pour le capteur Containerd.	Facultatif	`true` ou`false`. Par défaut :`false`
`com.instana.plugin.containerd.logs.sendInterval`	Disponible depuis : capteur Containerd 1.0.30. La durée maximale (en secondes) pendant laquelle les journaux des conteneurs restent en cache dans le capteur de journaux avant d'être transférés vers le backend.	Facultatif	1 à 600. Valeur par défaut : 60
`com.instana.plugin.containerd.logs.maxBufferSize`	Disponible depuis : capteur Containerd 1.0.30. La taille maximale du tampon de journalisation interne (en octets). Si le contenu du tampon de journalisation interne dépasse la taille maximale, le capteur de journalisation transfère alors ce contenu vers le backend Instana.	Facultatif	1000 à 32000000. Valeur par défaut : 16777216 (16 Mo)