datadog.datadog
Rôle Ansible de l'Agent Datadog
Le rôle Ansible de l'Agent Datadog installe et configure l'Agent Datadog ainsi que ses intégrations.
Rôle Ansible versus Collection Ansible
Le rôle Ansible de l'Agent Datadog est disponible via deux canaux différents :
- Dans le cadre de la collection Datadog, accessible sous le nom datadog.dd sur Ansible Galaxy (recommandé).
- En tant que rôle autonome, accessible sous le nom datadog.datadog sur Ansible Galaxy (héritage).
La version 4
du rôle et la version 5
de la collection installent par défaut l'Agent Datadog v7.
Configuration
Notez que les instructions d'installation dans ce document décrivent l'installation du rôle Datadog autonome. Pour les instructions d'installation de la collection Datadog, veuillez vous référer au README de la collection. Les variables de configuration sont les mêmes pour le rôle autonome ainsi que pour celui accessible via la collection.
Exigences
Nécessite Ansible v2.6+.
Prend en charge la plupart des distributions Linux basées sur Debian et RHEL, macOS et Windows.
Lors de l'utilisation avec Ansible 2.10+ pour gérer des hôtes Windows, il nécessite l'installation de la collection
ansible.windows
:ansible-galaxy collection install ansible.windows
Lors de l'utilisation avec Ansible 2.10+ pour gérer des hôtes openSUSE/SLES, il nécessite l'installation de la collection
community.general
:ansible-galaxy collection install community.general
Installation
Installez le rôle Datadog depuis Ansible Galaxy sur votre serveur Ansible :
ansible-galaxy install datadog.datadog
Pour déployer l'Agent Datadog sur des hôtes, ajoutez le rôle Datadog et votre clé API à votre playbook :
- hosts: servers
roles:
- { role: datadog.datadog, become: yes }
vars:
datadog_api_key: "<VOTRE_CLE_API_DD>"
La clé API est requise et son absence entraîne l'échec du rôle. Si vous souhaitez la fournir d'une manière différente, en dehors du contrôle d'Ansible, spécifiez une clé de remplacement et remplacez-la plus tard.
Variables de rôle
Ces variables offrent une configuration supplémentaire lors de l'installation de l'Agent Datadog. Elles doivent être spécifiées dans la section vars
de votre playbook.
Variable | Description |
---|---|
datadog_api_key |
Votre clé API Datadog. Cette variable est obligatoire à partir de la version 4.21. |
datadog_site |
Le site de l'entrée Datadog pour envoyer les données de l'Agent. La valeur par défaut est datadoghq.com , définissez-la sur datadoghq.eu pour envoyer des données vers le site UE. Cette option n'est disponible qu'avec la version de l'Agent >= 6.6.0. |
datadog_agent_flavor |
Remplacez le paquet Debian / RedHat par défaut pour les installations IoT sur RPI. Par défaut, il est "datadog-agent" - utilisez "datadog-iot-agent" pour RPI. |
datadog_agent_version |
La version fixée de l'Agent à installer (optionnelle, mais recommandée), par exemple : 7.16.0 . La définition de datadog_agent_major_version n'est pas nécessaire si datadog_agent_version est utilisée. |
datadog_agent_major_version |
La version majeure de l'Agent à installer. Les valeurs possibles sont 5, 6 ou 7 (par défaut). Si datadog_agent_version est définie, elle prévaut, sinon la dernière version de la version majeure spécifiée est installée. |
datadog_checks |
Configuration YAML pour les vérifications de l'Agent à déposer dans : - /etc/datadog-agent/conf.d/<check_name>.d/conf.yaml pour l'Agent v6 et v7, - /etc/dd-agent/conf.d pour l'Agent v5. |
datadog_disable_untracked_checks |
Défini sur true pour supprimer toutes les vérifications non présentes dans datadog_checks et datadog_additional_checks . |
datadog_additional_checks |
Liste de vérifications supplémentaires qui ne sont pas supprimées si datadog_disable_untracked_checks est défini sur true . |
datadog_disable_default_checks |
Défini sur true pour supprimer toutes les vérifications par défaut. |
datadog_config |
Définissez la configuration pour l'Agent Datadog. Le rôle écrit la config à l'emplacement correct en fonction du système d'exploitation. Pour une liste complète des options de configuration, consultez le fichier de modèle datadog.yaml dans le dépôt GitHub de datadog-agent. |
datadog_config_ex |
(Optionnel) Sections INI supplémentaires à placer dans /etc/dd-agent/datadog.conf (Agent v5 uniquement). |
datadog_apt_repo |
Remplacez le dépôt apt Datadog par défaut. Assurez-vous d'utiliser l'option signed-by si les métadonnées du dépôt sont signées à l'aide des clés de signature de Datadog : deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://yourrepo . |
datadog_apt_cache_valid_time |
Remplacez le temps d'expiration du cache apt par défaut (valeur par défaut 1 heure). |
datadog_apt_key_url_new |
Remplacez l'emplacement depuis lequel obtenir la clé apt de Datadog (la variable datadog_apt_key_url obsolète renvoie à une clé expirée qui a été supprimée du rôle). L'URL est censée être un trousseau de clés GPG contenant les clés 382E94DE , F14F620E et C0962C7D . |
datadog_yum_repo_config_enabled |
Défini sur false pour empêcher la configuration d'un dépôt yum Datadog (valeur par défaut true ). ATTENTION : cela désactive la mise à jour automatique des clés GPG. |
datadog_yum_repo |
Remplacez le dépôt yum Datadog par défaut. |
datadog_yum_repo_proxy |
Définissez une URL proxy à utiliser dans la configuration du dépôt yum de Datadog. |
datadog_yum_repo_proxy_username |
Définissez un nom d'utilisateur proxy à utiliser dans la configuration du dépôt yum de Datadog. |
datadog_yum_repo_proxy_password |
Définissez un mot de passe proxy à utiliser dans la configuration du dépôt yum de Datadog. |
datadog_yum_repo_gpgcheck |
Remplacez la valeur par défaut de repo_gpgcheck (vide). Si elle est vide, la valeur est définie dynamiquement sur yes lorsque le datadog_yum_repo personnalisé n'est pas utilisé et que le système n'est pas RHEL/CentOS 8.1 (en raison d'un bug dans dnf), sinon elle est définie sur no . Remarque : la vérification de la signature des données du dépôt est toujours désactivée pour l'Agent 5. |
datadog_yum_gpgcheck |
Remplacez la valeur par défaut de gpgcheck (yes ) - utilisez no pour désactiver la vérification de la signature GPG des paquets. |
datadog_yum_gpgkey |
Supprimée dans la version 4.18.0 Remplacez l'URL par défaut de la clé yum de Datadog utilisée pour vérifier les paquets de l'Agent v5 et v6 (jusqu'à 6.13) (ID de clé 4172A230 ). |
datadog_yum_gpgkey_e09422b3 |
Remplacez l'URL par défaut de la clé yum de Datadog utilisée pour vérifier les paquets de l'Agent v6.14+ (ID de clé E09422B3 ). |
datadog_yum_gpgkey_e09422b3_sha256sum |
Remplacez le checksum par défaut de la clé datadog_yum_gpgkey_e09422b3 . |
datadog_zypper_repo |
Remplacez le dépôt zypper Datadog par défaut. |
datadog_zypper_repo_gpgcheck |
Remplacez la valeur par défaut de repo_gpgcheck (vide). Si elle est vide, la valeur est définie dynamiquement sur yes lorsque le datadog_zypper_repo personnalisé n'est pas utilisé, sinon elle est définie sur no . Remarque : la vérification de la signature des données du dépôt est toujours désactivée pour l'Agent 5. |
datadog_zypper_gpgcheck |
Remplacez la valeur par défaut de gpgcheck (yes ) - utilisez no pour désactiver la vérification de la signature GPG des paquets. |
datadog_zypper_gpgkey |
Supprimée dans la version 4.18.0 Remplacez l'URL par défaut de la clé zypper de Datadog utilisée pour vérifier les paquets de l'Agent v5 et v6 (jusqu'à 6.13) (ID de clé 4172A230 ). |
datadog_zypper_gpgkey_sha256sum |
Supprimée dans la version 4.18.0 Remplacez le checksum par défaut de la clé datadog_zypper_gpgkey . |
datadog_zypper_gpgkey_e09422b3 |
Remplacez l'URL par défaut de la clé zypper de Datadog utilisée pour vérifier les paquets de l'Agent v6.14+ (ID de clé E09422B3 ). |
datadog_zypper_gpgkey_e09422b3_sha256sum |
Remplacez le checksum par défaut de la clé datadog_zypper_gpgkey_e09422B3 . |
datadog_agent_allow_downgrade |
Défini sur yes pour autoriser la rétrogradation de l'Agent (à utiliser avec précaution, voir defaults/main.yml pour les détails). Remarque : Les rétrogradations ne sont pas prises en charge sur les plateformes Windows. |
datadog_enabled |
Défini sur false pour empêcher le service datadog-agent de démarrer (valeur par défaut true ). |
datadog_additional_groups |
Soit une liste, soit une chaîne contenant une liste séparée par des virgules de groupes supplémentaires pour l'utilisateur datadog (Linux uniquement). |
datadog_windows_ddagentuser_name |
Le nom de l'utilisateur Windows à créer/utiliser, au format <domaine>\<utilisateur> (Windows uniquement). |
datadog_windows_ddagentuser_password |
Le mot de passe utilisé pour créer l'utilisateur et/ou enregistrer le service (Windows uniquement). |
datadog_apply_windows_614_fix |
Indique s'il faut ou non télécharger et appliquer le fichier référencé par datadog_windows_614_fix_script_url (Windows uniquement). Consultez https://dtdg.co/win-614-fix pour plus de détails. Vous pouvez définir cela sur false en supposant que vos hôtes ne fonctionnent pas avec Datadog Agent 6.14.*. |
datadog_macos_user |
Le nom de l'utilisateur sous lequel exécuter l'Agent. L'utilisateur doit exister, il ne sera pas créé automatiquement. La valeur par défaut est ansible_user (macOS uniquement). |
datadog_macos_download_url |
Remplacez l'URL pour télécharger le programme d'installation DMG (macOS uniquement). |
datadog_apm_instrumentation_enabled |
Configurez l'instrumentation APM. Valeurs possibles : - host : À la fois l'Agent et vos services fonctionnent sur un hôte. - docker : L'Agent et vos services fonctionnent dans des conteneurs Docker séparés sur le même hôte.- all : Prend en charge tous les scénarios précédents pour host et docker en même temps. |
datadog_apm_instrumentation_libraries |
Liste des bibliothèques APM à installer si l'injection host ou docker est activée (valeur par défaut : ["java", "js", "dotnet", "python", "ruby"] ). Vous pouvez trouver les valeurs disponibles dans Inject Libraries Locally. |
datadog_apm_instrumentation_docker_config |
Remplacez la configuration APM Docker. Consultez configurer l'injection Docker pour plus de détails. |
datadog_remote_updates |
Activez l'installation et les mises à jour distantes via le datadog-installer. |
Intégrations
Pour configurer une intégration Datadog (vérification), ajoutez une entrée à la section datadog_checks
. La clé de premier niveau est le nom de la vérification, et la valeur est la charge utile YAML à écrire dans le fichier de configuration. Des exemples sont fournis ci-dessous.
Pour installer ou supprimer une intégration, référez-vous au paragraphe datadog_integration
.
Vérification de processus
Pour définir deux instances pour la vérification process
, utilisez la configuration ci-dessous. Cela crée les fichiers de configuration correspondants :
- Agent v6 & v7 :
/etc/datadog-agent/conf.d/process.d/conf.yaml
- Agent v5 :
/etc/dd-agent/conf.d/process.yaml
datadog_checks:
process:
init_config:
instances:
- name: ssh
search_string: ['ssh', 'sshd']
- name: syslog
search_string: ['rsyslog']
cpu_check_interval: 0.2
exact_match: true
ignore_denied_access: true
Vérification personnalisée
Pour configurer une vérification personnalisée, utilisez la configuration ci-dessous. Cela crée les fichiers de configuration correspondants :
- Agent v6 & v7 :
/etc/datadog-agent/conf.d/my_custom_check.d/conf.yaml
- Agent v5 :
/etc/dd-agent/conf.d/my_custom_check.yaml
datadog_checks:
my_custom_check:
init_config:
instances:
- some_data: true
Vérifications Python personnalisées
Pour passer une vérification Python au playbook, utilisez la configuration ci-dessous.
Cette configuration nécessite que le play et le rôle Datadog fassent partie d'un playbook plus large où la valeur passée est le chemin relatif vers la tâche réelle pour Linux ou Windows.
Ceci est seulement disponible pour l'Agent v6 ou ultérieur.
La clé devrait correspondre au nom du fichier créé dans le répertoire des vérifications checks.d/{{ item }}.py
:
datadog_checks:
my_custom_check:
init_config:
instances:
- some_data: true
datadog_custom_checks:
my_custom_check: '../../../custom_checks/my_custom_check.py'
Autodécouverte
Lorsque vous utilisez l'autodécouverte, il n'y a pas de prétraitement ni de post-traitement sur le YAML. Cela signifie que chaque section YAML est ajoutée au fichier de configuration final, y compris les identifiants d'autodécouverte.
L'exemple ci-dessous configure la vérification PostgreSQL via l'autodécouverte :
datadog_checks:
postgres:
ad_identifiers:
- db-master
- db-slave
init_config:
instances:
- host: %%host%%
port: %%port%%
username: username
password: password
En savoir plus sur l'Autodécouverte dans la documentation de Datadog.
Traçage
Pour activer la collecte de traces avec l'Agent v6 ou v7, utilisez la configuration suivante :
datadog_config:
apm_config:
enabled: true
Pour activer la collecte de traces avec l'Agent v5, utilisez la configuration suivante :
datadog_config:
apm_enabled: "true" # doit être une chaîne
Processus en direct
Pour activer la collecte de processus en direct avec l'Agent v6 ou v7, utilisez la configuration suivante :
datadog_config:
process_config:
enabled: "true" # type : chaîne
Les valeurs possibles pour enabled
sont : "true"
, "false"
(collection uniquement des conteneurs) ou "disabled"
(désactiver complètement les processus en direct).
Variables
Les variables suivantes sont disponibles pour les processus en direct :
scrub_args
: Active le nettoyage des arguments sensibles d'une ligne de commande de processus (valeur par défaut :true
).custom_sensitive_words
: Étend la liste par défaut des mots sensibles utilisés par le nettoyeur de ligne de commande.
Probe système
La probe système est configurée sous la variable system_probe_config
. Toutes les variables imbriquées sont écrites dans le system-probe.yaml
, dans la section system_probe_config
.
La surveillance de la performance réseau (NPM) est configurée sous la variable network_config
. Toutes les variables imbriquées sont écrites dans le system-probe.yaml
, dans la section network_config
.
La sécurité des charges de travail dans le cloud est configurée sous la variable runtime_security_config
. Toutes les variables imbriquées sont écrites dans le system-probe.yaml
et le security-agent.yaml
, dans la section runtime_security_config
.
La surveillance des services universels (USM) est configurée sous la variable service_monitoring_config
. Toutes les variables imbriquées sont écrites dans le system-probe.yaml
, dans la section service_monitoring_config
.
Conformité est configurée sous la variable compliance_config
. Toutes les variables imbriquées sont écrites dans le security-agent.yaml
, dans la section compliance_config
.
Remarque pour les utilisateurs Windows : NPM est pris en charge sur Windows avec l'Agent v6.27+ et v7.27+. Il est fourni comme un composant optionnel qui n'est installé que si network_config.enabled
est défini sur true lors de l'installation ou de la mise à niveau de l'Agent. Pour cette raison, les installations existantes peuvent nécessiter de désinstaller et de réinstaller l'Agent une fois pour installer le composant NPM, sauf si l'Agent est mis à niveau en même temps.
Exemple de configuration
datadog_config:
process_config:
enabled: "true" # type : chaîne
scrub_args: true
custom_sensitive_words: ['consul_token','dd_api_key']
system_probe_config:
sysprobe_socket: /opt/datadog-agent/run/sysprobe.sock
network_config:
enabled: true
service_monitoring_config:
enabled: true
runtime_security_config:
enabled: true
Remarque : Cette configuration fonctionne avec l'Agent 6.24.1+ et 7.24.1+. Pour les versions d'Agent plus anciennes, consultez la documentation de la surveillance de la performance réseau sur la façon d'activer le probe système.
Sur Linux, une fois cette modification terminée, suivez les étapes ci-dessous si vous avez installé une version de l'Agent antérieure à 6.18.0 ou 7.18.0 :
- Démarrez le probe système :
sudo service datadog-agent-sysprobe start
Remarque : Si le service wrapper n'est pas disponible sur votre système, exécutez cette commande à la place :sudo initctl start datadog-agent-sysprobe
. - Redémarrez l'Agent:
sudo service datadog-agent restart
. - Activez le probe système pour qu'il démarre au démarrage :
sudo service enable datadog-agent-sysprobe
.
Pour une configuration manuelle, consultez la documentation de la NPM.
Agent v5
Pour activer la collecte de processus en direct avec l'Agent v5, utilisez la configuration suivante :
datadog_config:
process_agent_enabled: true
datadog_config_ex:
process.config:
scrub_args: true
custom_sensitive_words: "<PREMIER_MOT>,<DEUXIEME_MOT>"
Versions
Par défaut, la version majeure actuelle du rôle Ansible Datadog installe l'Agent v7. Les variables datadog_agent_version
et datadog_agent_major_version
sont disponibles pour contrôler la version de l'Agent installée.
Pour les versions v4+ de ce rôle, lorsque datadog_agent_version
est utilisé pour fixer une version spécifique de l'Agent, le rôle dérive des noms de version par OS pour se conformer aux schémas de nommage des versions des systèmes d'exploitation pris en charge, par exemple :
1:7.16.0-1
pour Debian et SUSE basées7.16.0-1
pour les versions basées sur RedHat7.16.0-1
pour macOS7.16.0
pour Windows.
Cela permet de cibler les hôtes exécutant différents systèmes d'exploitation dans le même exécution Ansible, par exemple :
Fournie | Installe | Système |
---|---|---|
datadog_agent_version: 7.16.0 |
1:7.16.0-1 |
Debian et SUSE basés |
datadog_agent_version: 7.16.0 |
7.16.0-1 |
Basé sur RedHat |
datadog_agent_version: 7.16.0 |
7.16.0-1 |
macOS |
datadog_agent_version: 7.16.0 |
7.16.0 |
Windows |
datadog_agent_version: 1:7.16.0-1 |
1:7.16.0-1 |
Debian et SUSE basés |
datadog_agent_version: 1:7.16.0-1 |
7.16.0-1 |
Basé sur RedHat |
datadog_agent_version: 1:7.16.0-1 |
7.16.0 |
Windows |
Remarque : Si la version n'est pas fournie, le rôle utilise 1
comme l'époque et 1
comme le numéro de version.
Agent v5 (version plus ancienne) :
Le rôle Ansible Datadog inclut un support pour l'Agent Datadog v5 seulement pour Linux. Pour installer l'Agent v5, utilisez datadog_agent_major_version: 5
pour installer la dernière version de l'Agent v5 ou définissez datadog_agent_version
sur une version spécifique de l'Agent v5. Remarque : La variable datadog_agent5
est obsolète et a été supprimée.
Dépôts
Linux
Lorsque les variables datadog_apt_repo
, datadog_yum_repo
, et datadog_zypper_repo
ne sont pas définies, les dépôts officiels Datadog pour la version majeure définie dans datadog_agent_major_version
sont utilisés :
# | Dépôt apt par défaut | Dépôt yum par défaut | Dépôt zypper par défaut |
---|---|---|---|
5 | deb https://apt.datadoghq.com stable main | https://yum.datadoghq.com/rpm | https://yum.datadoghq.com/suse/rpm |
6 | deb https://apt.datadoghq.com stable 6 | https://yum.datadoghq.com/stable/6 | https://yum.datadoghq.com/suse/stable/6 |
7 | deb https://apt.datadoghq.com stable 7 | https://yum.datadoghq.com/stable/7 | https://yum.datadoghq.com/suse/stable/7 |
Pour remplacer le comportement par défaut, définissez ces variables sur quelque chose d'autre qu'une chaîne vide.
Si vous avez précédemment utilisé les variables Agent v5, utilisez les nouvelles variables ci-dessous avec datadog_agent_major_version
défini sur 5
ou datadog_agent_version
fixé à une version spécifique de l'Agent v5.
Ancien | Nouveau |
---|---|
datadog_agent5_apt_repo |
datadog_apt_repo |
datadog_agent5_yum_repo |
datadog_yum_repo |
datadog_agent5_zypper_repo |
datadog_zypper_repo |
Depuis la version 4.9.0, la variable use_apt_backup_keyserver
a été supprimée, car les clés APT sont obtenues depuis https://keys.datadoghq.com.
Windows
Lorsque la variable datadog_windows_download_url
n'est pas définie, le package MSI Windows officiel correspondant à datadog_agent_major_version
est utilisé :
Version de l'Agent | URL par défaut du package MSI Windows |
---|---|
6 | https://s3.amazonaws.com/ddagent-windows-stable/datadog-agent-6-latest.amd64.msi |
7 | https://s3.amazonaws.com/ddagent-windows-stable/datadog-agent-7-latest.amd64.msi |
Pour remplacer le comportement par défaut, définissez cette variable sur autre chose qu'une chaîne vide.
macOS
Lorsque la variable datadog_macos_download_url
n'est pas définie, le package DMG macOS officiel correspondant à datadog_agent_major_version
est utilisé :
Version de l'Agent | URL par défaut du package DMG macOS |
---|---|
6 | https://install.datadoghq.com/datadog-agent-6-latest.dmg |
7 | https://install.datadoghq.com/datadog-agent-7-latest.dmg |
Pour remplacer le comportement par défaut, définissez cette variable sur autre chose qu'une chaîne vide.
Mise à niveau
Pour passer de l'Agent v6 à v7, utilisez datadog_agent_major_version: 7
pour installer la dernière version ou définissez datadog_agent_version
sur une version spécifique de l'Agent v7. Utilisez une logique similaire pour mettre à niveau de l'Agent v5 à v6.
Installation d'intégration
Disponible pour l'Agent v6.8+
Utilisez la ressource datadog_integration
pour installer une version spécifique d'une intégration Datadog. Gardez à l'esprit que l'Agent est déjà livré avec les intégrations principales installées. Cette commande est utile pour mettre à niveau une intégration spécifique sans mettre à niveau l'ensemble de l'Agent. Pour plus de détails, voir gestion des intégrations.
Si vous souhaitez configurer une intégration, référez-vous au paragraphe datadog_checks
.
Actions disponibles :
install
: Installe une version spécifique de l'intégration.remove
: Supprime une intégration.
Intégrations de tiers
Les intégrations communauté Datadog et Marché Datadog peuvent être installées avec la ressource datadog_integration
. Remarque : Ces intégrations sont considérées comme des "tiers" et nécessitent que third_party: true
soit défini - voir l'exemple ci-dessous.
Syntaxe
datadog_integration:
<NOM_D_INTRÉGRATION>:
action: <ACTION>
version: <VERSION_A_INSTALLER>
Pour installer des intégrations de tiers, définissez third_party
sur true :
datadog_integration:
<NOM_D_INTRÉGRATION>:
action: <ACTION>
version: <VERSION_A_INSTALLER>
third_party: true
Exemple
Cet exemple installe la version 1.11.0
de l'intégration ElasticSearch et supprime l'intégration postgres
.
datadog_integration:
datadog-elastic:
action: install
version: 1.11.0
datadog-postgres:
action: remove
Pour voir les versions disponibles des intégrations Datadog, consultez leur fichier CHANGELOG.md
dans le dépôt intégrations-core.
Rétrogradation
Pour rétrograder à une version antérieure de l'Agent :
- Définissez
datadog_agent_version
sur une version spécifique, par exemple :5.32.5
. - Définissez
datadog_agent_allow_downgrade
suryes
.
Remarques :
- Les rétrogradations ne sont pas prises en charge pour les plateformes Windows.
Playbooks
Voici quelques exemples de playbooks pour vous aider à utiliser le rôle Ansible Datadog.
Le suivant exemple envoie des données vers Datadog US (par défaut), active les logs, NPM et configure quelques vérifications.
- hosts: servers
roles:
- { role: datadog.datadog, become: yes }
vars:
datadog_api_key: "<VOTRE_CLE_API_DD>"
datadog_agent_version: "7.16.0"
datadog_config:
tags:
- "<CLE>:<VALEUR>"
- "<CLE>:<VALEUR>"
log_level: INFO
apm_config:
enabled: true
logs_enabled: true # disponible avec l'Agent v6 et v7
datadog_checks:
process:
init_config:
instances:
- name: ssh
search_string: ['ssh', 'sshd' ]
- name: syslog
search_string: ['rsyslog' ]
cpu_check_interval: 0.2
exact_match: true
ignore_denied_access: true
ssh_check:
init_config:
instances:
- host: localhost
port: 22
username: root
password: <VOTRE_MOT_DE_PASSE>
sftp_check: True
private_key_file:
add_missing_keys: True
nginx:
init_config:
instances:
- nginx_status_url: http://example.com/nginx_status/
tags:
- "source:nginx"
- "instance:foo"
- nginx_status_url: http://example2.com:1234/nginx_status/
tags:
- "source:nginx"
- "<CLE>:<VALEUR>"
# La collecte de logs est disponible sur l'Agent 6 et 7
logs:
- type: file
path: /var/log/access.log
service: myapp
source: nginx
sourcecategory: http_web_access
- type: file
path: /var/log/error.log
service: nginx
source: nginx
sourcecategory: http_web_access
# datadog_integration est disponible sur l'Agent 6.8+
datadog_integration:
datadog-elastic:
action: install
version: 1.11.0
datadog-postgres:
action: remove
network_config:
enabled: true
Agent v6
Cet exemple installe le dernier Agent v6 :
- hosts: servers
roles:
- { role: datadog.datadog, become: yes }
vars:
datadog_agent_major_version: 6
datadog_api_key: "<VOTRE_CLE_API_DD>"
Configurer le site
Si vous utilisez un site autre que le datadoghq.com
par défaut, définissez la variable datadog_site
sur l'URL appropriée (par ex : datadoghq.eu
, us3.datadoghq.com
).
Cet exemple envoie des données vers le site UE :
- hosts: servers
roles:
- { role: datadog.datadog, become: yes }
vars:
datadog_site: "datadoghq.eu"
datadog_api_key: "<VOTRE_CLE_API_DD>"
Windows
Sur Windows, retirez l'option become: yes
pour que le rôle ne plante pas. Voici deux méthodes pour faire fonctionner les exemples de playbooks avec des hôtes Windows :
Fichier d'inventaire
L'utilisation du fichier d'inventaire est l'approche recommandée. Définissez l'option ansible_become
sur no
dans le fichier d'inventaire pour chaque hôte Windows :
[servers]
linux1 ansible_host=127.0.0.1
linux2 ansible_host=127.0.0.2
windows1 ansible_host=127.0.0.3 ansible_become=no
windows2 ansible_host=127.0.0.4 ansible_become=no
Pour éviter de répéter la même configuration pour tous les hôtes Windows, regroupez-les et définissez la variable au niveau du groupe :
[linux]
linux1 ansible_host=127.0.0.1
linux2 ansible_host=127.0.0.2
[windows]
windows1 ansible_host=127.0.0.3
windows2 ansible_host=127.0.0.4
[windows:vars]
ansible_become=no
Fichier de playbook
Alternativement, si votre playbook ne s'exécute que sur des hôtes Windows, utilisez ce qui suit dans le fichier du playbook :
- hosts: servers
roles:
- { role: datadog.datadog }
vars:
...
Remarque : Cette configuration échoue sur les hôtes Linux. Utilisez-la uniquement si le playbook est spécifique aux hôtes Windows. Sinon, utilisez la méthode du fichier d'inventaire.
Désinstallation
Sur Windows, il est possible de désinstaller l'Agent en utilisant le code suivant dans votre rôle Ansible :
- name: Vérifiez si l'Agent Datadog est installé
win_shell: |
(@(Get-ChildItem -Path "HKLM:SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" -Recurse) | Where {$_.GetValue("DisplayName") -like "Datadog Agent" }).PSChildName
register: agent_installed_result
- name: Définit un fait installé pour l'Agent Datadog
set_fact:
agent_installed: "{{ agent_installed_result.stdout | trim }}"
- name: Désinstaller l'Agent Datadog
win_package:
product_id: "{{ agent_installed }}"
state: absent
when: agent_installed != ""
Dépannage
Debian stretch
Remarque: cette information s'applique aux versions du rôle avant 4.9.0. Depuis 4.9.0, le module apt_key
n'est plus utilisé par le rôle.
Sur Debian Stretch, le module apt_key
utilisé par le rôle nécessite une dépendance système supplémentaire pour fonctionner correctement. La dépendance (dirmngr
) n'est pas fournie par le module. Ajoutez la configuration suivante à vos playbooks pour tirer parti du rôle présent :
---
- hosts: all
pre_tasks:
- name: Debian Stretch nécessite le paquet dirmngr pour utiliser apt_key
become: yes
apt:
name: dirmngr
state: present
roles:
- { role: datadog.datadog, become: yes }
vars:
datadog_api_key: "<VOTRE_CLE_API_DD>"
CentOS 6/7 avec interpréteur Python 3 et Ansible 2.10.x ou inférieur
Le module Python yum
, qui est utilisé dans ce rôle pour installer l'Agent sur les hôtes basés sur CentOS, n'est disponible que sur Python 2 si Ansible 2.10.x ou inférieur est utilisé. Dans ce cas, le gestionnaire de paquets dnf
devrait être utilisé à la place.
Cependant, dnf
et le module Python dnf
ne sont pas installés par défaut sur les hôtes basés sur CentOS avant CentOS 8. Dans ce cas, il n'est pas possible d'installer l'Agent lorsque l'interpréteur Python 3 est utilisé.
Ce rôle échoue tôt lorsque cette situation est détectée pour indiquer qu'Ansible 2.11+ ou un interpréteur Python 2 est nécessaire lors de l'installation de l'Agent sur CentOS / RHEL < 8.
Pour contourner cette détection d'échec précoce (par exemple, si dnf
et le paquet python3-dnf
sont disponibles sur votre hôte), définissez la variable datadog_ignore_old_centos_python3_error
sur true
.
Windows
En raison d'un bug critique dans les versions de l'Agent 6.14.0
et 6.14.1
sur Windows, l'installation de ces versions est bloquée (à partir de la version 3.3.0
de ce rôle).
REMARQUE : Ansible échoue sur Windows si datadog_agent_version
est réglé sur 6.14.0
ou 6.14.1
. Utilisez 6.14.2
ou supérieur.
Si vous mettez à jour depuis 6.14.0 ou 6.14.1 sur Windows, suivez ces étapes :
- Mettez à jour le rôle Ansible
datadog.datadog
vers la dernière version (>=3.3.0
). - Définissez la
datadog_agent_version
sur6.14.2
ou supérieure (valeur par défaut à la dernière version).
Pour plus de détails, consultez le bug critique dans le désinstallateur pour l'Agent Datadog 6.14.0 et 6.14.1 sur Windows.
Ubuntu 20.04 bloqué par service_facts
L'exécution du module service_facts
sur Ubuntu 20.04 génère l'erreur suivante :
localhost | FAILED! => {
"changed": false,
"msg": "Malformed output discovered from systemd list-unit-files: accounts-daemon.service enabled enabled "
}
Pour résoudre cela, mettez à jour Ansible vers v2.9.8
ou supérieur.
Clé API manquante
À partir de la version du rôle 4.21
, la clé API est obligatoire pour que le rôle puisse procéder.
Si vous devez installer l'agent via Ansible mais ne souhaitez pas spécifier de clé API (si par exemple vous l'intégrez dans une image de conteneur/VM), vous pouvez :
- Spécifier une clé API fictive et la remplacer ultérieurement
- Désactiver la configuration gérée (
datadog_manage_config: false
)
ansible-galaxy install datadog.datadog