Fonction Autodiscovery de l'Agent
Présentation
Dans une infrastructure conteneurisée, les conteneurs peuvent basculer d’un host à un autre, ce qui complique leur surveillance. En raison du dynamisme des systèmes conteneurisés, la surveillance manuelle n’est pas une chose aisée.
Pour y remédier, vous pouvez utiliser la fonction Autodiscovery de Datadog afin d’identifier automatiquement les services qui s’exécutent sur un conteneur précis et de rassembler des données sur ces services. Lorsqu’un conteneur se lance, l’Agent Datadog identifie les services qui s’y exécutent, recherche la configuration de surveillance correspondante et initie la collecte de métriques.
La fonction Autodiscovery vous permet de définir des modèles de configuration pour des checks d’Agent et de spécifier les conteneurs sur lesquels chaque check doit s’appliquer.
L’Agent recherche des événements de création, destruction, démarrage ou encore d’arrêt de conteneur avant d’activer, de désactiver et de régénérer les configurations de check statiques lors de ces événements. Lorsque l’Agent inspecte les conteneurs en cours d’exécution, il vérifie si chaque conteneur correspond à l’un des identifiants de conteneur Autodiscovery présents dans les modèles chargés. À chaque correspondance, l’Agent génère une configuration de check statique en remplaçant les template variables par les valeurs spécifiques du conteneur correspondant. Il active ensuite le check avec la configuration statique.
Fonctionnement
Le schéma ci-dessus représente un nœud de host avec trois pods, notamment un pod Redis et un pod d’Agent. Le Kubelet, qui planifie les conteneurs, s’exécute en tant que binaire sur ce nœud et expose les endpoints /metrics
et /pods
. Toutes les 10 secondes, l’Agent interroge /pods
et trouve les spécifications Redis. Il peut également consulter les informations sur le pod Redis.
Dans cet exemple, les spécifications Redis comprennent les annotations suivantes :
labels:
tags.datadoghq.com/redis.env: "prod"
tags.datadoghq.com/redis.service: "my-redis"
tags.datadoghq.com/redis.version: "6.0.3"
annotations:
ad.datadoghq.com/redis.checks: |
{
"redisdb": {
"init_config": {},
"instances": [
{
"host": "%%host%%",
"port":"6379",
"password":"%%env_REDIS_PASSWORD%%"
}
]
}
}
ad.datadoghq.com/redis.logs: '[{"source":"redis"}]'
Dans l’exemple ci-dessus, les étiquettes tags.datadoghq.com
sont utilisées pour appliquer les valeurs env
, service
et même version
sous forme de tags à l’ensemble des logs et métriques envoyés par le pod Redis. Ces étiquettes standard font partie du système de tagging de service unifié. Datadog vous conseille d’utiliser le tagging de service unifié lorsque vous configurez des tags et des variables d’environnement.
redisdb
correspond au nom du check à exécuter. init_config
est facultatif et indique certains paramètres de configuration, comme l’intervalle minimum de collecte. Chaque élément de instances
représente la configuration à exécuter sur une instance d’un check. Remarque : ici, %%host%%
est une template variable dont la valeur correspond automatiquement à l’adresse IP de votre conteneur.
labels:
tags.datadoghq.com/redis.env: "prod"
tags.datadoghq.com/redis.service: "my-redis"
tags.datadoghq.com/redis.version: "6.0.3"
annotations:
ad.datadoghq.com/redis.check_names: '["redisdb"]'
ad.datadoghq.com/redis.init_configs: '[{}]'
ad.datadoghq.com/redis.instances: |
[
{
"host": "%%host%%",
"port":"6379",
"password":"%%env_REDIS_PASSWORD%%"
}
]
ad.datadoghq.com/redis.logs: '[{"source":"redis"}]'
Dans l’exemple ci-dessus, les étiquettes tags.datadoghq.com
sont utilisées pour appliquer les valeurs env
, service
et même version
sous forme de tags à l’ensemble des logs et métriques envoyés par le pod Redis. Ces étiquettes standard font partie du système de tagging de service unifié. Datadog vous conseille d’utiliser le tagging de service unifié lorsque vous configurez des tags et des variables d’environnement.
check_names
comprend les noms des checks à exécuter, tandis qu’init_configs
indique certains paramètres de configuration, comme l’intervalle minimum de collecte. Chaque élément d’instances
représente la configuration à exécuter sur une instance d’un check. Remarque : ici, %%host%%
est une template variable dont la valeur correspond automatiquement à l’adresse IP de votre conteneur.
L’Agent génère ainsi une configuration de check statique.
Configuration
Il vous suffit de suivre les deux étapes suivantes pour configurer Autodiscovery pour votre infrastructure :
- Activez Autodiscovery sur votre Agent Datadog.
- Créez des modèles de configuration spécifiques à chaque intégration pour chaque service à surveiller. Remarque : Datadog fournit des modèles de configuration automatique pour certains services conteneurisés populaires, comme Apache et Redis.
Activer Autodiscovery
En plus de détecter les sockets et endpoints d’API disponibles (tels que Docker, containerd et l’API Kubernetes), l’Agent active Autodiscovery automatiquement.
Si Autodiscovery ne fonctionne pas, vérifiez les fonctionnalités détectées en exécutant agent status
.
Si la détection automatique a échoué ou que vous souhaitez désactiver des fonctionnalités détectées automatiquement, utilisez les paramètres de configuration suivants dans datadog.yaml
pour inclure ou exclure des fonctionnalités :
autoconfig_exclude_features:
- docker
autoconfig_include_features:
- containerd
La liste complète des fonctionnalités détectées automatiquement est disponible dans le modèle datadog.yaml
.
Modèles d’intégration
Une fois la fonction Autodiscovery activée, l’Agent Datadog essaie automatiquement de l’utiliser pour plusieurs services, notamment Apache et Redis, en se basant sur les fichiers de configuration Autodiscovery par défaut.
Vous pouvez définir un modèle d’intégration de plusieurs façons : avec des annotations de pod Kubernetes, des étiquettes Docker, un fichier de configuration monté sur l’Agent, une ConfigMap ou encore des stockages key/value. Consultez la section Modèles d’intégration Autodiscovery pour en savoir plus.
Remarques
Si vous utilisez la fonctionnalité Autodiscovery et qu’une application est déployée dans un nouveau nœud, il est possible que les métriques ne s’affichent pas de suite dans Datadog. En effet, lorsque vous basculez vers un nouveau nœud, l’Agent Datadog met du temps à recueillir les métadonnées de votre application.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles: