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édentNouveau nomRemarques
proxy_hostproxyLes 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_metadataenable_metadata_collectionActive la connecte de métadonnées.
collector_log_filelog_file
syslog_hostsyslog_uriLa configuration de Syslog est exprimée sous forme d’URI.
syslog_pemCertificat client Syslog configuré pour la validation du client TLS.
syslog_keyClé privée client Syslog configurée pour la validation du client TLS.
Options supprimées
NomRemarques
proxy_portRemplacée par proxy. Consultez la documentation dédiée au proxy pour en savoir plus.
proxy_userRemplacée par proxy. Consultez la documentation dédiée au proxy pour en savoir plus.
proxy_passwordRemplacée par proxy. Consultez la documentation dédiée au proxy pour en savoir plus.
proxy_forbid_method_switchObsolète
use_mountDésormais associée au check Disk au lieu de l’Agent.
device_blacklist_reDésormais associée au check Disk sous le nom de device_blacklist au lieu de l’Agent.
use_curl_http_clientObsolète
exclude_process_argsFonctionnalité obsolète
check_timingsRemplacée par les statistiques internes
non_local_trafficRemplacée par dogstatsd_non_local_traffic pour Dogstatsd et par apm_config.apm_non_local_traffic pour l’Agent de trace.
dogstatsd_target
dogstreamsFonctionnalité obsolète. Utilisez l’Agent de logs à la place.
custom_emitters
forwarder_log_fileRemplacée par log_file
dogstatsd_log_fileRemplacée par log_file
jmxfetch_log_fileRemplacée par log_file
syslog_portRemplacée par syslog_uri
check_freq
collect_orchestrator_tagsImplémentée dans les collecteurs de métadonnées
utf8_decoding
developer_mode
use_forwarder
autorestart
dogstream_logFonctionnalité obsolète. Utilisez l’Agent de logs à la place.
use_curl_http_client
collect_security_groupsFonctionnalité 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 :

OptionDescription
min_collection_intervalDé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_hostnameLorsque définie sur true, permet d’envoyer des métriques, événements et checks de service sans hostname.
tagsEnvoyer 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’environnementDescription
DD_PROXY_HTTPL’URL à utiliser comme proxy pour les requêtes http.
DD_PROXY_HTTPSL’URL à utiliser comme proxy pour les requêtes https.
DD_PROXY_NO_PROXYUne 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.

Des différences existent au niveau de la résolution du hostname entre l’Agent v5 et l’Agent v6. Pour en savoir plus, consultez la section Comment Datadog détermine-t-il le hostname de l’Agent.

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 :

<BINAIRE_AGENT> --help

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 :

CommandeDescription
sudo service datadog-agent startDémarrer l’Agent en tant que service.
sudo service datadog-agent stopArrêter le service de l’Agent.
sudo service datadog-agent restartRedémarrer le service de l’Agent.
sudo service datadog-agent statusAfficher 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 initupstartsystemdsysvinitRemarques
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 11Non 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 v5Commande dans l’Agent v6Remarques
sudo service datadog-agent infosudo datadog-agent statusPage de statut de l’Agent lorsqu’il est en cours d’exécution
sudo service datadog-agent flaresudo datadog-agent flareEnvoyer un flare
sudo service datadog-agentsudo datadog-agent --helpAfficher 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 v5Commande dans l’Agent v6Description
datadog-agent startlaunchctl start com.datadoghq.agent ou barre des menusDémarrer l’Agent en tant que service
datadog-agent stoplaunchctl stop com.datadoghq.agent ou barre des menusArrêter le service de l’Agent
datadog-agent restartexécuter stop puis start ou barre des menusRedémarrer le service de l’Agent
datadog-agent statuslaunchctl list com.datadoghq.agent ou barre des menusAfficher le statut du service de l’Agent
datadog-agent infodatadog-agent status ou interface graphique WebPage de statut de l’Agent lorsqu’il est en cours d’exécution
datadog-agent flaredatadog-agent flare ou interface graphique WebEnvoyer un flare
pas implémentédatadog-agent --helpAfficher 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 :

CommandeDescription
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 collectDé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