Nouveautés de l'Agent v6
Présentation
L’Agent v6 de Datadog contient de nombreuses nouveautés par rapport aux versions précédentes. Les changements et fonctionnalités dépréciées sont détaillés dans les sections ci-dessous.
Fonctionnalités
Les fonctionnalités de l’Agent v5 suivantes ne sont pas disponibles dans l’Agent v6 :
Configuration
Dans les anciennes versions de l’Agent, les fichiers de configuration sont stockés dans /etc/dd-agent
. À partir de l’Agent v6.0+, les fichiers sont stockés dans /etc/datadog-agent
.
Le fichier de configuration principal de l’Agent est désormais au format YAML et non au format INI, ceci afin de prendre en charge les configurations complexes tout en harmonisant l’expérience de configuration de l’Agent et des checks.
Agent v5 datadog.conf
–> Agent v6 datadog.yaml
Pour appliquer le nouveau format et les nouveaux chemins de configuration de l’Agent, utilisez la commande suivante :
sudo -u dd-agent -- datadog-agent import
Cette commande parse le fichier datadog.conf
existant et convertit les paramètres pris en charge au nouveau format dans datadog.yaml
. Elle copie également les fichiers de configuration des checks activés. Pour en savoir plus, consultez Upgrade vers l’Agent v6 de Datadog.
Options
Les options de configuration de l’Agent suivantes ont été modifiées ou supprimées dans l’Agent v6. Les options de configuration supprimées ont été remplacées par d’autres options ou concernent des fonctionnalités qui fonctionnent différemment par rapport aux versions précédentes.
Options modifiées
Nom précédent | Nouveau nom | Remarques |
---|
proxy_host | proxy | Les paramètres de proxy sont spécifiés en tant que liste d’URI. Consultez la documentation dédiée au proxy pour en savoir plus. |
collect_instance_metadata | enable_metadata_collection | Active la connecte de métadonnées. |
collector_log_file | log_file | |
syslog_host | syslog_uri | La configuration de Syslog est exprimée sous forme d’URI. |
| syslog_pem | Certificat client Syslog configuré pour la validation du client TLS. |
| syslog_key | Clé privée client Syslog configurée pour la validation du client TLS. |
Options supprimées
Nom | Remarques |
---|
proxy_port | Remplacée par proxy . Consultez la documentation dédiée au proxy pour en savoir plus. |
proxy_user | Remplacée par proxy . Consultez la documentation dédiée au proxy pour en savoir plus. |
proxy_password | Remplacée par proxy . Consultez la documentation dédiée au proxy pour en savoir plus. |
proxy_forbid_method_switch | Obsolète |
use_mount | Désormais associée au check Disk au lieu de l’Agent. |
device_blacklist_re | Désormais associée au check Disk sous le nom de device_blacklist au lieu de l’Agent. |
use_curl_http_client | Obsolète |
exclude_process_args | Fonctionnalité obsolète |
check_timings | Remplacée par les statistiques internes |
non_local_traffic | Remplacée par dogstatsd_non_local_traffic pour Dogstatsd et par apm_config.apm_non_local_traffic pour l’Agent de trace. |
dogstatsd_target | |
dogstreams | Fonctionnalité obsolète. Utilisez l’Agent de logs à la place. |
custom_emitters | |
forwarder_log_file | Remplacée par log_file |
dogstatsd_log_file | Remplacée par log_file |
jmxfetch_log_file | Remplacée par log_file |
syslog_port | Remplacée par syslog_uri |
check_freq | |
collect_orchestrator_tags | Implémentée dans les collecteurs de métadonnées |
utf8_decoding | |
developer_mode | |
use_forwarder | |
autorestart | |
dogstream_log | Fonctionnalité obsolète. Utilisez l’Agent de logs à la place. |
use_curl_http_client | |
collect_security_groups | Fonctionnalité obsolète. Désormais disponible avec l’intégration AWS. |
L’Agent v6 charge tous les fichiers YAML valides présents dans <RÉPERTOIRE_AGENT>/conf.d/<NOM_CHECK>.d/
. Vous avez ainsi la possibilité de créer des configurations complexes décomposées en plusieurs fichiers.
Par exemple, les fichiers de configuration pour le http_check
peuvent être :
/etc/datadog-agent/conf.d/http_check.d/
├── backend.yaml
└── frontend.yaml
L’Agent ne charge pas les fichiers de configuration présents dans les sous-répertoires du dossier <NOM_CHECK>.d
. Par exemple, le fichier suivant ne sera pas chargé :
/etc/datadog-agent/conf.d/http_check.d/prod.d/
├── backend.yaml
Les fichiers de modèle Autodiscovery (auto_conf.yaml
) sont également stockés dans le répertoire de configuration. Voici un exemple de dossier de configuration pour le check redisdb
:
/etc/datadog-agent/conf.d/redisdb.d/
├── auto_conf.yaml
└── conf.yaml.example
Le nom des fichiers YAML dans un dossier <NOM_CHECK>.d
n’a aucune importance : les fichiers doivent simplement avoir pour extension .yaml
ou .yml
. Le nom standard est conf.yaml
.
Pour préserver la compatibilité avec les versions précédentes, l’Agent récupère toujours les fichiers de configuration au format <RÉPERTOIRE_AGENT>/conf.d/<NOM_CHECK>.yaml
. Toutefois, la migration vers le nouveau format est fortement conseillée.
Options de configuration
L’Agent v6 prend en charge les options suivantes dans la section instance
d’un check :
Option | Description |
---|
min_collection_interval | Définir un intervalle d’exécution différent (en secondes) pour les checks qui doivent être exécutés moins souvent que toutes les 15 secondes (l’intervalle par défaut). |
empty_default_hostname | Lorsque définie sur true , permet d’envoyer des métriques, événements et checks de service sans hostname. |
tags | Envoyer des tags personnalisés en plus des tags envoyés par le check. |
La plupart des variables d’environnement utilisées dans l’Agent v6 sont différentes de celles des versions précédentes. Consultez la liste des variables d’environnement pour l’Agent v6.
Remarque : DD_TAGS
utilise les mêmes tags, mais ces derniers sont séparés par des espaces dans l’Agent v6. Dans les versions précédentes, ils étaient séparés par des virgules. Exemple pour l’Agent v6 : DD_TAGS="simple-tag-0 tag-key-1:tag-value-1"
Proxies
À partir de la v6.4.0+, les paramètres de proxy de l’Agent peuvent être remplacés via les variables d’environnement suivantes :
Variable d’environnement | Description |
---|
DD_PROXY_HTTP | L’URL à utiliser comme proxy pour les requêtes http . |
DD_PROXY_HTTPS | L’URL à utiliser comme proxy pour les requêtes https . |
DD_PROXY_NO_PROXY | Une liste d’URL, séparées par des espaces, pour lesquelles aucun proxy ne doit être utilisé. |
Les variables d’environnement standard (HTTP_PROXY
, HTTPS_PROXY
et NO_PROXY
) sont prises en charge dans l’Agent v6, mais nous vous conseillons d’utiliser les variables DD_PROXY_*
. Les variables DD_PROXY_*
sont appliquées en priorité sur les autres.
Dans l’Agent v6, l’ordre de priorité des options de proxy est différent par rapport aux versions précédentes :
- L’Agent v6 applique les variables d’environnement en premier, puis le fichier de configuration.
- L’Agent v6 remplace les valeurs du fichier de configuration par celles de l’environnement. Par exemple, si les options
proxy.http
et proxy.https
sont définies dans le fichier de configuration mais que seule la variable DD_PROXY_HTTPS
est définie dans l’environnement, l’Agent applique la valeur https
de l’environnement et la valeur http
du fichier de configuration.
Logs
Les fichiers de logs de l’Agent se situent toujours dans /var/log/datadog/
(Linux) et C:\ProgramData\Datadog\logs
(Windows).
Dans les anciennes versions, les logs étaient écrits dans différents fichiers (collector.log
, forwarder.log
, dogstatsd.log
, etc). Les logs de l’Agent v6 sont écrits dans un seul fichier : agent.log
.
Interface
L’interface de ligne de commande pour l’Agent v6 est basée sur un système de sous-commandes. Pour consulter la liste des sous-commandes disponibles, exécutez ce qui suit :
Pour exécuter une sous-commande, vous devez appeler le binaire de l’Agent :
<BINAIRE_AGENT> <SOUS_COMMANDE> <OPTIONS>
Certaines options disposent de flags et d’options détaillées que vous pouvez consulter avec --help
. Par exemple, pour afficher les informations d’aide de la sous-commande check
:
<BINAIRE_AGENT> check --help
Pour obtenir la liste de toutes les commandes disponibles, consultez Commandes de l’Agent.
Changements propres au système d’exploitation
Sous Linux, les changements majeurs dans l’Agent v6 sont les suivants :
- Seules les commandes de cycle de vie (
start
/stop
/restart
/status
) doivent être exécutées avec sudo service
/sudo initctl
/sudo systemctl
. - Toutes les autres commandes doivent être invoquées avec le binaire de l’Agent, situé dans le
PATH
(/usr/bin
) en tant que datadog-agent
par défaut. La commande dd-agent
n’est plus disponible. - La sous-commande
info
a été renommée status
. - L’Agent v6 n’intègre pas de script SysV-init (anciennement situé à l’emplacement
/etc/init.d/datadog-agent
).
Commandes de cycle de vie du service
Les commandes de cycle de vie restent les mêmes si la commande du wrapper service
est disponible sur votre système.
Par exemple, sous Ubuntu, les commandes de cycle de vie sont les suivantes :
Commande | Description |
---|
sudo service datadog-agent start | Démarrer l’Agent en tant que service. |
sudo service datadog-agent stop | Arrêter le service de l’Agent. |
sudo service datadog-agent restart | Redémarrer le service de l’Agent. |
sudo service datadog-agent status | Afficher le statut du service de l’Agent. |
Si la commande du wrapper service
n’est pas disponible sur votre système, utilisez :
- Sur les systèmes basés sur
upstart
: sudo start/stop/restart/status datadog-agent
- Sur les systèmes basés sur
systemd
: sudo systemctl start/stop/restart/status datadog-agent
Si vous ne savez pas quel système init votre distribution utilise par défaut, consultez le tableau ci-dessous :
distribution \ système init | upstart | systemd | sysvinit | Remarques |
---|
Amazon Linux (<= 2017.09) | | | | |
Amazon Linux 2 (>= 2017.12) | | | | |
CentOS/RHEL 6 | | | | |
CentOS/RHEL 7 | | | | |
Debian 7 (wheezy) | | | (Agent v6.6.0+) | |
Debian 8 (jessie) et 9 (stretch) | | | | |
SUSE 11 | | | | Non pris en charge sans systemd |
SUSE 12 | | | | |
Ubuntu < 15.04 | | | | |
Ubuntu >= 15.04 | | | | |
Commandes de l’Agent
Avec l’Agent v6+, certaines fonctionnalités sont fournies par le binaire de l’Agent lui-même en tant que sous-commandes et ne doivent pas être invoquées avec service
/systemctl
/initctl
. Voici quelques exemples :
Commande dans l’Agent v5 | Commande dans l’Agent v6 | Remarques |
---|
sudo service datadog-agent info | sudo datadog-agent status | Page de statut de l’Agent lorsqu’il est en cours d’exécution |
sudo service datadog-agent flare | sudo datadog-agent flare | Envoyer un flare |
sudo service datadog-agent | sudo datadog-agent --help | Afficher l’utilisation de l’Agent |
sudo -u dd-agent -- dd-agent check <NOM_CHECK> | sudo -u dd-agent -- datadog-agent check <NOM_CHECK> | Exécuter un check |
Sous Windows, les changements majeurs dans l’Agent v6 sont les suivants :
- L’interface graphique de Datadog Agent Manager pour Windows utilisée par l’Agent v5 a été remplacée par une interface de gestion cross-platform qui s’utilise depuis un navigateur. Pour en savoir plus, consultez la section Datadog Agent Manager pour Windows.
- Le nom du fichier exécutable principal est
agent.exe
(contre ddagent.exe
précédemment). - Les commandes doivent être exécutées en utilisant la syntaxe
"%PROGRAMFILES%\datadog\datadog agent\embedded\agent.exe" <COMMANDE>
depuis une invite de commande avec droits Administrateur : - Le type de démarrage du service Windows est défini sur « Automatique (début différé) ». Le service est démarré au lancement de Windows, mais après tous les autres services. Cela signifie que l’envoi des métriques est légèrement retardé après un redémarrage.
- L’interface graphique Windows et l’icône de la barre des menus sont implémentées séparément. Pour en savoir plus, consultez la section Datadog Agent Manager pour Windows.
Sous macOS, les changements majeurs dans l’Agent v6 sont les suivants :
- Les commandes de cycle de vie (auparavant
datadog-agent start
/stop
/restart
/status
) sont remplacées par les commandes launchctl
sur le service com.datadoghq.agent
et doivent être exécutées depuis le compte utilisateur connecté. Vous pouvez également exécuter ces commandes depuis la barre des menus de l’Agent Datadog. - Toutes les autres commandes peuvent toujours être exécutées avec le binaire
datadog-agent
situé dans le PATH
(/usr/local/bin/
) par défaut. - La commande
info
a été renommée status
. - L’interface de configuration graphique est une application basée sur un navigateur. Pour y accéder, exécutez la commande
datadog-agent launch-gui
ou utilisez la barre des menus.
Exemples de changements :
Commande dans l’Agent v5 | Commande dans l’Agent v6 | Description |
---|
datadog-agent start | launchctl start com.datadoghq.agent ou barre des menus | Démarrer l’Agent en tant que service |
datadog-agent stop | launchctl stop com.datadoghq.agent ou barre des menus | Arrêter le service de l’Agent |
datadog-agent restart | exécuter stop puis start ou barre des menus | Redémarrer le service de l’Agent |
datadog-agent status | launchctl list com.datadoghq.agent ou barre des menus | Afficher le statut du service de l’Agent |
datadog-agent info | datadog-agent status ou interface graphique Web | Page de statut de l’Agent lorsqu’il est en cours d’exécution |
datadog-agent flare | datadog-agent flare ou interface graphique Web | Envoyer un flare |
pas implémenté | datadog-agent --help | Afficher l’utilisation des commandes |
datadog-agent check <NOM_CHECK> | datadog-agent check <NOM_CHECK> | Exécuter un check (pas de changement) |
Agents de collecte
L’Agent APM est intégré au package de l’Agent v6 sous Linux, macOS et Windows.
L’Agent APM est activé par défaut sous Linux. Pour l’activer sur une autre plateforme ou le désactiver sous Linux, modifiez la clé apm_config
dans votre datadog.yaml
:
apm_config:
enabled: true
Si vous utilisez l’image Docker, l’Agent APM est désactivé par défaut. Activez-le en définissant DD_APM_ENABLED
sur true
. L’Agent écoute toutes les interfaces par défaut. Si vous souhaitez écouter le trafic non local sur une autre plateforme, définissez DD_APM_NON_LOCAL_TRAFFIC
sur true
. Pour en savoir plus, consultez Tracer des applications Docker.
L’Agent de processus est intégré au package de l’Agent v6 sous Linux uniquement.
L’Agent de processus n’est pas activé par défaut. Pour l’activer, modifiez votre datadog.yaml
comme suit :
process_config:
enabled: "true"
La valeur enabled
est une chaîne avec les options suivantes :
"true"
: activer la collecte des processus et des conteneurs par l’Agent de processus."false"
(par défaut) : recueillir les conteneurs uniquement (lorsque cela est possible)."disabled"
: ne pas exécuter l’Agent de processus.
Checks
L’Agent v6 prend en charge les versions 1.12 et ultérieures de Docker.
Le check Docker a été réécrit en Go pour tirer parti de l’architecture interne de l’Agent. La version Python (docker_daemon
) est donc désormais obsolète.
Le nouveau check est nommé docker
. La commande import de l’Agent permet d’importer les paramètres de l’ancienne configuration docker_daemon.yaml
. Toutes les fonctionnalités ont été portées, à l’exception des suivantes :
url
, api_version
et tags*
sont obsolètes. Nous vous conseillons d’utiliser les variables d’environnement Docker standard.ecs_tags
, performance_tags
et container_tags
sont obsolètes. Tous ces tags sont désormais recueillis par défaut.- Il n’est plus possible d’utiliser
collect_container_count
pour activer la métrique docker.container.count
. Vous devez utiliser docker.containers.running
et .stopped
.
Certaines options ont été déplacées du fichier docker_daemon.yaml
vers le fichier datadog.yaml
principal :
collect_labels_as_tags
a été renommé docker_labels_as_tags
et prend désormais en charge les tags dotés d’une cardinalité élevée. Consultez la section Appliquer et extraire des tags pour en savoir plus.- Les listes
exclude
et include
ont été renommées ac_include
et ac_exclude
. Afin d’obtenir un filtrage cohérent entre tous les composants de l’Agent, le filtrage des tags arbitraires a été abandonné. Les seuls tags de filtrage pris en charge sont image
(nom de l’image) et name
(nom du conteneur). Le filtrage à l’aide d’expressions régulières est toujours disponible. Consultez Gestion de la découverte de conteneurs pour en savoir plus. - L’option
docker_root
a été divisée en deux options : container_cgroup_root
et container_proc_root
. exclude_pause_container
a été ajouté afin d’exclure les conteneurs en pause sur Kubernetes et Openshift (valeur par défaut : true
).
L’Agent v6 prend en charge les versions 1.3 et ultérieures de Kubernetes.
L’intégration Kubernetes fournit des informations pertinentes en combinant :
- Les métriques du check Kubelet recueillies à partir du kubelet
- Les événements du check kubernetes_apiserver et les checks de service recueillis à partir du serveur d’API
La commande import de l’Agent (v6.2+) permet d’importer les paramètres de l’ancienne configuration kubernetes.yaml
. Les options suivantes sont désormais obsolètes :
- Informations d’authentification au serveur d’API (
api_server_url
, apiserver_client_crt
, apiserver_client_key
, apiserver_ca_cert
) : désormais, vous devez spécifier un fichier kubeconfig
à l’Agent avec kubernetes_kubeconfig_path
. use_histogram
: contactez l’assistance Datadog pour déterminer l’alternative la plus adaptée à vos besoins.namespaces
et namespace_name_regexp
: l’Agent v6 recueille les métriques à partir de tous les espaces de nommage disponibles.
La nouvelle logique permet de rendre la collecte de métriques Prometheus compatible avec les versions 1.7.6+ de Kubernetes. Si vous utilisez une version plus ancienne ou que vous souhaitez rétablir la logique de collecte de cadvisor, définissez cadvisor_port
sur 4194
(le port sur lequel votre kubelet expose cadvisor).
Le check kubernetes_state fonctionne avec l’Agent v5 ou l’Agent v6.
Tagging
Si l’Agent v5 recueillait automatiquement toutes les étiquettes de pod en tant que tags, l’Agent v6 utilise une liste d’autorisation. Pour modifier cette liste, utilisez l’option kubernetes_pod_labels_as_tags
dans datadog.yaml
. Consultez la documentation relative à l’application et à l’extraction des tags pour en savoir plus.
Les options et tags suivants sont désormais obsolètes :
label_to_tag_prefix
a été remplacée par kubernetes_pod_labels_as_tags
.- Les tags
container_alias
ne sont plus recueillis. kube_replicate_controller
est uniquement ajouté si le pod a été créé par un replication controller. Utilisez plutôt le tag creator pertinent (kube_deployment
, kube_daemon_set
, etc.).
L’Agent v6 intègre JMXFetch. Les changements sont les suivants :
Jmxterm
L’Agent v6 n’intègre pas le JAR jmxterm
. Pour télécharger et utiliser jmxterm
, consultez le projet upstream.
Commandes de dépannage
La syntaxe des commandes de dépannage a été modifiée. Ces commandes sont valables pour les versions v6.2.0+ ; pour les versions plus anciennes, consultez la documentation relative au dépannage de l’Agent JMX :
Commande | Description |
---|
sudo -u dd-agent datadog-agent jmx list matching | Énumérer les attributs qui correspondent à au moins l’une de vos configurations d’instance. |
sudo -u dd-agent datadog-agent jmx list limited | Énumérer les attributs qui correspondent à l’une de vos configurations d’instance, mais qui ne sont pas recueillis afin de ne pas dépasser le nombre maximum de métriques pouvant être recueillies. |
sudo -u dd-agent datadog-agent jmx list collected | Énumérer les attributs recueillis par vos configurations d’instance actuelles. |
sudo -u dd-agent datadog-agent jmx list not-matching | Énumérer les attributs qui ne correspondent à aucune de vos configurations d’instance. |
sudo -u dd-agent datadog-agent jmx list everything | Énumérer l’ensemble des attributs disponibles dont le type est pris en charge par JMXFetch. |
sudo -u dd-agent datadog-agent jmx collect | Démarrer la collecte de métriques en fonction de votre configuration actuelle et les afficher dans la console. |
Remarque : par défaut, ces commandes sont exécutées sur tous les checks JMX configurés. Pour spécifier un check, utilisez le flag --checks
. Exemple :
sudo datadog-agent jmx list collected --checks tomcat
Affecte uniquement les Agents Windows
Avec l’Agent v5 sous Windows, les métriques system.mem.pagefile.*
affichent des unités incohérentes (erronées de 10^6).
Ce problème est résolu par la v6 de l’Agent pour Windows, mais l’erreur reste présente dans la v5 de l’Agent, pour des raisons de rétrocompatibilité. Par conséquent, les valeurs envoyées (et les moniteurs associés) sont amenées à changer après une mise à niveau vers la v6.
Autodiscovery
Le système Autodiscovery a été repensé dans l’Agent v6. De plus, les runtimes et les orchestrateurs de conteneur ont été découplés pour plus de flexibilité. Ce changement se traduit notamment par le passage de docker_images
à ad_identifiers
dans les modèles.
Lorsque vous utilisez Kubernetes, Autodiscovery extrait les informations du kubelet au lieu du daemon Docker. Autodiscovery peut ainsi fonctionner sans accéder au socket Docker. De plus, par défaut, les modèles Autodiscovery sont récupérés à partir des annotations des pods. Vous pouvez activer le config-provider docker
pour utiliser les étiquettes de conteneurs, et remplacer l’écouteur kubelet
par l’écouteur Docker si vous avez besoin d’utiliser Autodiscovery sur des conteneurs à court de pods.
Lorsque vous spécifiez des modèles Autodiscovery dans des annotations de pod, le préfixe du nom de l’annotation est ad.datadoghq.com/
. Le préfixe d’annotation précédent (service-discovery.datadoghq.com/
) est toujours pris en charge par l’Agent v6, mais cette compatibilité sera supprimée dans une future version.
Les modèles Autodiscovery dans les étiquettes Docker fonctionnent avec le même préfixe de nom, com.datadoghq.ad.*
.
L’étiquette utilisée pour remplacer l’identificateur s’intitule com.datadoghq.ad.check.id
, au lieu de com.datadoghq.sd.check.id
, pour plus de cohérence. L’ancien nom est toujours pris en charge par l’Agent v6, mais cette compatibilité sera supprimée dans une future version.
Modules Python
Avec l’Agent v6, l’ensemble du code Python lié aux checks est importé depuis l’espace de nommage datadog_checks
. La plupart des bibliothèques Python présentes dans l’Agent v5 sont intégrées à l’Agent v6. Il existe toutefois quelques différences :
util.py
et ses fonctionnalités associées ont été supprimées de l’Agent v6.util.headers(...)
est toujours intégré à l’Agent v6, mais il est implémenté en C et Go et passé au check.
Remarque : toutes les intégrations officielles ont été mises à jour pour supprimer les modules obsolètes. Ces changements n’affectent que les checks custom.
Une grande partie du répertoire utils
a été supprimée de l’Agent v6, mais la majorité du contenu supprimé n’était pas directement lié aux checks. Le module flare, par exemple, a été supprimé et réimplémenté en Go, mais il est peu probable qu’il ait déjà été utilisé dans un check custom. Pour en savoir plus, consultez la documentation dédiée à la création de checks custom.
Bien que l’Agent v6 prenne entièrement en charge les checks Python, certaines intégrations officielles de l’Agent v5 ont été supprimées ou remplacées :
La classe principale pour les checks Python (AgentCheck
) est importée depuis datadog_checks.base.checks
. Plusieurs fonctions ont été supprimées ou modifiées dans l’API de la classe. De plus, chaque instance de check est désormais sa propre instance de classe. Il n’est donc plus possible de partager un statut entre plusieurs instances.
Les méthodes suivantes de la classe AgentCheck
ne sont pas implémentées :
service_metadata
get_service_metadata
generate_historate_func
generate_histogram_func
stop
La signature de fonction des émetteurs de métriques a été modifiée :
# Anciennes versions
gauge(self, metric, value, tags=None, hostname=None, device_name=None, timestamp=None)
# Agent v6
gauge(self, name, value, tags=None, hostname=None, device_name=None)
Les méthodes suivantes ont été définitivement supprimées de la classe AgentCheck
:
_roll_up_instance_metadata
instance_count
is_check_enabled
read_config
set_check_version
set_manifest_path
_get_statistic_name_from_method
_collect_internal_stats
_get_internal_profiling_stats
_set_internal_profiling_stats
get_library_versions
get_library_info
from_yaml
get_service_checks
has_warnings
get_metrics
has_events
get_events
Remarque : toutes les intégrations officielles ont été mises à jour pour supprimer les méthodes obsolètes. Ces changements n’affectent que les checks custom.
Priorité
Avec l’Agent v6, les checks officiels ont la priorité sur les checks custom (situés dans <RÉPERTOIRE_AGENT>/checks.d
). Les checks custom portant le même nom qu’un check officiel sont ignorés.
Pour corriger la configuration de vos checks avec l’Agent v6, donnez un nouveau nom unique aux checks custom affectés, puis renommez les fichiers de configuration .yaml
associés.
Dépendances
Si vous utilisez des checks custom, il est possible que votre code fasse appel à du code Python qui n’est plus intégré à l’Agent v6. Les packages suivants ne sont plus inclus dans l’Agent :
- backports.ssl-match-hostname
- datadog
- decorator
- future
- futures
- google-apputils
- pycurl
- pyOpenSSL
- python-consul
- python-dateutil
- python-etcd
- python-gflags
- pytz
- PyYAML
- rancher-metadata
- tornado
- uptime
- websocket-client
Si votre code fait appel à l’un de ces packages, installez le package manquant en exécutant :
sudo -u dd-agent -- /opt/datadog-agent/embedded/bin/pip install <NOM_PACKAGE>
De la même manière, vous avez peut-être ajouté un package PIP pour répondre à une exigence d’un check custom lorsque vous utilisiez l’Agent v5. Si le package PIP ajouté avait des dépendances internes avec des packages intégrés à l’Agent v5 (voir la liste ci-dessus), ces dépendances seront perdues après un passage à l’Agent v6. Installez les dépendances manquantes comme décrit ci-dessus.
Pour aller plus loin
Documentation, liens et articles supplémentaires utiles: