Les live containers de Datadog vous permettent de bénéficier d’une réelle visibilité sur l’ensemble des conteneurs de votre environnement.
Inspirés d’outils Bedrock comme htop, ctop et kubectl, les live containers vous offrent une vue d’ensemble globale de votre infrastructure de conteneurs. Leur tableau, régulièrement mis à jour, présente les métriques de ressources actualisées toutes les deux secondes, dispose d’une fonction de recherche à facettes et affiche les logs de conteneur sous forme de flux.
Associée à Docker, Kubernetes, ECS ou d’autres technologies de conteneur, ainsi qu’à la fonction intégrée de tagging de composants dynamiques, la vue des live containers fournit une présentation détaillée de la santé de vos conteneurs, de leur consommation en ressources, de leurs logs et de leur déploiement en temps réel :
L’Agent Datadog et l’Agent de cluster peuvent être configurés afin de récupérer des ressources Kubernetes pour des live containers. Cela vous permet de surveiller l’état de vos pods, déploiements et autres entités Kubernetes dans un espace de nommage ou une zone de disponibilité précise. Il est également possible de consulter les spécifications de ressources pour les échecs de pods d’un déploiement ou encore de mettre en corrélation l’activité d’un nœud avec les logs associés.
Avant d’effectuer les configurations ci-dessous pour les ressources Kubernetes des live containers, il est nécessaire d’installer au minimum la version 7.21.1 de l’Agent ainsi que la version 1.9.0 de l’Agent de cluster.
Si vous utilisez le chart Helm Datadog officiel :
datadog.orchestratorExplorer.enabled sur true dans values.yaml.Dans certaines configurations, il arrive que l’Agent de processus et l’Agent de cluster ne parviennent pas à détecter automatiquement un nom de cluster Kubernetes. Lorsque c’est le cas, la fonctionnalité ne démarre pas et une entrée WARN est ajoutée aux logs de l’Agent de cluster, avec le message suivant : Orchestrator explorer enabled but no cluster name set: disabling. Vous devez alors définir datadog.clusterName sur le nom de votre cluster dans values.yaml.
La version 1.9.0 ou une version ultérieure de l'Agent de cluster est requise pour commencer la configuration du DaemonSet. L’Agent de cluster doit être en cours d’exécution et l’Agent doit pouvoir communiquer avec celui-ci. Consultez la section Configuration de l’Agent de cluster pour en savoir plus.
Définissez le conteneur de l’Agent de cluster à l’aide de la variable d’environnement suivante :
- name: DD_ORCHESTRATOR_EXPLORER_ENABLED
value: "true"
Définissez le ClusterRole de l’Agent de cluster à l’aide des autorisations RBAC suivantes.
Notez bien que pour les apiGroups apps, les live containers ont besoin d’autorisations
pour recueillir des ressources kubernetes (pods, services, nodes, etc.)
qui devraient déjà se trouver dans le RBAC si vous avez suivi la documentation relative à la configuration de l’Agent de cluster.
Si elles sont absentes, ajoutez-les (après
deployments, replicasets) :
ClusterRole:
- apiGroups: # To create the datadog-cluster-id CM
- ""
resources:
- configmaps
verbs:
- create
- get
- update
...
- apiGroups: # Required to get the kube-system namespace UID and generate a cluster ID
- ""
resources:
- namespaces
verbs:
- get
...
- apiGroups: # To collect new resource types
- "apps"
resources:
- deployments
- replicasets
# Below are in case RBAC was not setup from the above linked "Cluster Agent Setup documentation"
- pods
- nodes
- services
verbs:
- list
- get
- watch
Ces autorisations sont requises pour créer une ConfigMap datadog-cluster-id dans le même espace de nommage que le DaemonSet de l’Agent et le déploiement de l’Agent de cluster, mais également pour recueillir les déploiements et les ReplicaSets.
Si la ConfigMap cluster-id n’est pas créée par l’Agent de cluster, le pod de l’Agent n’est pas initié, ce qui génère le statut CreateContainerConfigError. Si le pod de l’Agent est bloqué par l’absence de cette ConfigMap, modifiez les autorisations de l’Agent de cluster et redémarrez ses pods pour permettre la création de la CongifMap. Le pod de l’Agent récupèrera automatiquement un statut normal.
L’Agent de processus, qui s’exécute dans le DaemonSet de l’Agent, doit être activé et en cours d’exécution. La collecte de processus ne doit pas forcément être en cours. Les options suivantes doivent également être configurées :
- name: DD_ORCHESTRATOR_EXPLORER_ENABLED
value: "true"
- name: DD_ORCHESTRATOR_CLUSTER_ID
valueFrom:
configMapKeyRef:
name: datadog-cluster-id
key: id
Dans certaines configurations, il arrive que l’Agent de processus et l’Agent de cluster ne parviennent pas à détecter automatiquement un nom de cluster Kubernetes. Lorsque c’est le cas, la fonctionnalité ne démarre pas et une entrée WARN est ajoutée aux logs de l’Agent de cluster, avec le message suivant : Orchestrator explorer enabled but no cluster name set: disabling. Vous devez alors définir ajouter les options suivantes dans la section env de l’Agent de cluster et de l’Agent de processus :
- name: DD_CLUSTER_NAME
value: "<NOM_CLUSTER>"
Il est possible d’inclure et/ou d’exclure des conteneurs pour la collecte en temps réel :
DD_CONTAINER_EXCLUDE ou ajoutez container_exclude: dans le fichier de configuration principal datadog.yaml.DD_CONTAINER_INCLUDE ou ajoutez container_include: dans le fichier de configuration principal datadog.yaml.Ces deux arguments ont pour valeur un nom d’image. Les expressions régulières sont également prises en charge.
Par exemple, pour exclure toutes les images Debian à l’exception des conteneurs dont le nom commence par frontend, ajoutez les deux lignes de configuration suivantes dans votre fichier datadog.yaml :
env:
- name: DD_LOGS_ENABLED
value: "true"
- name: DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL
value: "true"
volumeMounts:
- name: pointerdir
mountPath: /opt/datadog-agent/run
volumes:
- hostPath:
path: /opt/datadog-agent/run
name: pointerdir
container_exclude: ["image:debian"]
container_include: ["name:frontend.*"]
Remarque : pour la version 5 de l’Agent, au lieu d’ajouter les lignes ci-dessus dans le fichier de configuration principal datadog.conf, ajoutez explicitement un fichier datadog.yaml dans /etc/datadog-agent/. En effet, l’Agent de processus exige que toutes les options de configuration se trouvent à cet emplacement. Cette configuration exclut uniquement les conteneurs de la collecte en temps réel, et non de la fonction Autodiscovery.
Rendez-vous sur la page Containers pour accéder automatiquement à la vue des Conteneurs.
Les conteneurs sont, de par leur nature, des objets avec une très forte cardinalité. La recherche de texte flexible de Datadog permet de rechercher des sous-chaînes correspondantes dans le champ name, ID ou image d’un conteneur.
Si vous avez activé la fonctionnalité Ressources Kubernetes, vous avez la possibilité d’effectuer des recherches parmi les chaînes pod, deployment, ReplicaSet et service name ainsi que parmi les étiquettes Kubernetes dans une vue Ressources Kubernetes.
Pour combiner plusieurs recherches textuelles au sein d’une requête complexe, vous pouvez utiliser l’un des opérateurs booléens suivants :
| Opérateur | Description | Exemple |
AND | Intersection : les deux termes figurent dans les événements sélectionnés (si aucun opérateur n’est ajouté, AND est utilisé par défaut). | java AND elasticsearch |
OR | Union : un des deux termes figure dans les événements sélectionnés. | java OR python |
NOT / ! | Exclusion : le terme suivant n’est PAS dans l’événement. Vous pouvez utiliser le mot NOT ou le caractère ! pour effectuer la même opération. | java NOT elasticsearch équivalent : java !elasticsearch |
Utilisez des parenthèses pour regrouper des opérateurs. Par exemple, (NOT (elasticsearch OR kafka) java) OR python.
La capture d’écran ci-dessous illustre un système filtré de façon à visualiser un cluster Kubernetes composé de neuf nœuds. La charge RSS et la charge processeur des conteneurs sont affichées et comparées aux limites provisionnées pour les conteneurs (le cas échéant). Dans cet exemple, on constate que les conteneurs de ce cluster sont surprovisionnés. Vous pouvez définir des limites plus strictes et faire appel au bin packing pour optimiser l’utilisation des ressources.
Les environnements de conteneur sont dynamiques et peuvent être difficiles à surveiller. La capture d’écran ci-dessous illustre une vue qui a été pivotée par kube_service et host, et filtrée par kube_namespace:default dans le but de réduire les données parasite liées au système. Vous pouvez voir où les différents services sont exécutés, ainsi que le degré de saturation des métriques clés :
Pour analyser l’évolution de l’utilisation des ressources entre les différentes mises à jour, vous pouvez faire pivoter les données en fonction des paramètres ecs_task_name et ecs_task_version d’ECS.
Pour les ressources Kubernetes, sélectionnez les tags Datadog à utiliser pour filtrer les données, par exemple environment, service ou pod_phase. Vous pouvez également utiliser les facettes de conteneur sur la gauche pour visualiser une ressource Kubernetes spécifique. Regroupez vos pods en fonction de tags Datadog pour obtenir une vue agrégée et retrouver des informations plus rapidement.
Les conteneurs sont tagués avec tous les tags au niveau des hosts existants, ainsi qu’avec les métadonnées associées à chaque conteneur.
Le tag image_name est ajouté à tous les conteneurs, y compris les intégrations avec des orchestrateurs couramment utilisés, telles que ECS et Kubernetes, qui fournissent davantage de tags au niveau des conteneurs. De plus, chaque conteneur est doté d’une icône Docker, ECS ou Kubernetes afin de pouvoir identifier en quelques secondes les conteneurs orchestrés.
Les conteneurs ECS possèdent les tags suivants :
task_nametask_versionecs_clusterLes conteneurs Kubernetes possèdent les tags suivants :
pod_namekube_pod_ipkube_servicekube_namespacekube_replica_setkube_daemon_setkube_jobkube_deploymentkube_clusterSI vous avez configuré le tagging de service unifié, les tags env, service, et version sont également recueillis automatiquement.
L’utilisation de ces tags vous permet d’assurer la cohésion des données de l’APM, des logs, des métriques et des live containers.
Grâce à la vue Conteneurs, vous pouvez visualiser vos données sous forme de nuage de points ou de série temporelle. La vue comprend également un tableau vous permettant de trier les données de vos conteneurs selon différents champs, comme le nom du conteneur, son statut et sa date de démarrage.
Utilisez l’analyse de nuage de points pour comparer deux métriques entre elles et ainsi mieux comprendre les performances de vos conteneurs.
Pour accéder à l’analyse de nuage de points dans la page Containers, cliquez sur le bouton Show Summary graph, puis sélectionnez l’onglet « Scatter Plot » :
Par défaut, le graphique regroupe les données à partir de la clé de tag short_image. La taille de chaque point dépend du nombre de conteneurs du groupe. Lorsque vous cliquez sur un point, cela affiche chaque conteneur et host qui contribue au groupe.
La requête en haut de la fenêtre vous permet de contrôler les différentes options de l’analyse de nuage de points :
Lorsque vous utilisez activement la page des conteneurs, les métriques sont recueillies toutes les deux secondes. Cette particularité est très importante pour les métriques hautement volatiles, telles que l’utilisation du processeur. En arrière-plan, pour le contexte historique, les métriques sont recueillies toutes les 10 secondes.
Si vous avez activé la fonctionnalité Ressources Kubernetes pour Live Containers, utilisez le menu déroulant View en haut à gauche de chaque page pour basculer entre les vues Pods, Deployments, ReplicaSets et Services . Chacune de ces vues comprend un tableau de données pour vous aider à mieux organiser vos données par champ (nom, statut, etc.) et par étiquettes Kubernetes, ainsi qu’une Cluster Map détaillée pour obtenir une vue d’ensemble de vos pods et clusters Kubernetes.
Les Cluster Maps Kubernetes vous offrent une vue d’ensemble de vos pods et clusters Kubernetes. Vous pouvez visualiser toutes vos ressources depuis un seul écran en définissant des groupes et des filtres personnalisés, et choisir les métriques à utiliser pour colorer les pods.
Pour analyser en détail une ressource spécifique depuis la Cluster Map, cliquez sur un cercle ou un groupe. Les détails apparaîtront alors dans un volet distinct.
Cliquez sur une ligne du tableau ou sur un objet de la Cluster Map pour afficher des informations sur une ressource spécifique dans un volet latéral. Ce volet est utile pour le dépannage et pour trouver des informations sur un conteneur ou une ressource, comme par exemple :
DNS ou ip_type, ou utilisez le filtre Group by dans cette vue pour regrouper vos données réseau par tag, tel que pod_name ou service.Les vues Ressources Kubernetes comprennent également les onglets suivants :
Pour obtenir un dashboard détaillé de cette ressource, cliquez sur l’option View Dashboard en haut à droite de ce volet.
Visualisez le flux de logs d’un conteneur, tel que docker logs -f ou kubectl logs -f, dans Datadog. Cliquez sur un conteneur dans le tableau pour afficher davantage d’informations. Cliquez sur l’onglet Logs pour visualiser en temps réel les données Live Tail ou les logs indexés historiques, peu importe leur date.
Avec la fonctionnalité Live Tail, tous les logs de conteneur sont diffusés sous forme de flux. Mettez un flux en pause pour lire facilement le contenu des logs en cours d’écriture. Vous pouvez ensuite réactiver la mise à jour du flux.
Vous pouvez effectuer des recherches parmi les logs du flux à l’aide d’une simple correspondance textuelle. Pour en savoir plus sur la fonctionnalité Live Tail, consultez la documentation dédiée.
Remarque : les logs diffusés ne sont pas persistants. Si vous saisissez une nouvelle recherche ou actualisez la page, le contenu du flux est effacé.
Choisissez un intervalle pour afficher les logs correspondants que vous avez choisis d’indexer et de rendre persistants. L’indexation vous permet de filtrer vos logs à l’aide de tags et de facettes. Par exemple, pour rechercher des logs affichant le statut Error, saisissez status:error dans la zone de recherche. La fonction de saisie automatique peut vous aider à trouver le tag de votre choix. Les attributs clés de vos logs sont déjà stockés dans des tags, ce qui vous permet de les rechercher, filtrer et agréger en cas de besoin.
health correspond à la sonde de disponibilité des conteneurs, et non à leur sonde d’activité.Documentation, liens et articles supplémentaires utiles:
