{"id":14984433,"url":"https://github.com/datadog/ansible-datadog","last_synced_at":"2025-05-15T11:04:10.524Z","repository":{"id":37097264,"uuid":"20684278","full_name":"DataDog/ansible-datadog","owner":"DataDog","description":"Ansible role for Datadog Agent","archived":false,"fork":false,"pushed_at":"2025-04-09T14:17:27.000Z","size":747,"stargazers_count":303,"open_issues_count":24,"forks_count":226,"subscribers_count":240,"default_branch":"main","last_synced_at":"2025-04-14T16:59:56.061Z","etag":null,"topics":["ansible-galaxy","ansible-role","datadog","datadog-agent"],"latest_commit_sha":null,"homepage":"","language":"Jinja","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/DataDog.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2014-06-10T12:27:01.000Z","updated_at":"2025-04-10T18:58:23.000Z","dependencies_parsed_at":"2023-02-11T13:45:34.805Z","dependency_job_id":"f2c45e36-d5bd-445b-b213-148816ff4544","html_url":"https://github.com/DataDog/ansible-datadog","commit_stats":{"total_commits":464,"total_committers":122,"mean_commits":3.80327868852459,"dds":0.8836206896551724,"last_synced_commit":"68e6641720310a42a811eefeddeb80c22fdb47be"},"previous_names":[],"tags_count":63,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DataDog%2Fansible-datadog","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DataDog%2Fansible-datadog/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DataDog%2Fansible-datadog/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/DataDog%2Fansible-datadog/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/DataDog","download_url":"https://codeload.github.com/DataDog/ansible-datadog/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":248923721,"owners_count":21183951,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ansible-galaxy","ansible-role","datadog","datadog-agent"],"created_at":"2024-09-24T14:09:02.593Z","updated_at":"2025-05-15T11:04:10.516Z","avatar_url":"https://github.com/DataDog.png","language":"Jinja","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Datadog Agent Ansible Role\n\nThe Datadog Agent Ansible role installs and configures the Datadog Agent and integrations.\n\n## Ansible role versus Ansible collection\n\nThe Datadog Agent Ansible role is available through 2 different channels:\n\n* As part of the Datadog collection, accessible under the [datadog.dd](https://galaxy.ansible.com/ui/repo/published/datadog/dd/) name on Ansible Galaxy (recommended).\n* As a standalone role, accessible under the [datadog.datadog](https://galaxy.ansible.com/ui/standalone/roles/DataDog/datadog/) name on Ansible Galaxy (legacy).\n\nVersion `4` of the role and version `5` of the collection install the Datadog Agent v7 by default.\n\nVersion `5` of the role and version `6` of the collection no longer support Python 2, Agent 5, or Ansible versions below 2.10. It also no longer supports older versions of Amazon Linux 2 and CentOS. \n\n## Setup\n\nNote that the install instructions in this document describe installation of the standalone Datadog role. For installation instructions of the Datadog collection, please refer to [the collection README file](https://github.com/ansible-collections/Datadog/blob/main/README.md). The configuration variables are the same for both the standalone role as well as the role accessed through the collection.\n\n### Requirements\n\n- Requires Ansible v2.10+.\n- Supports most Debian and RHEL-based Linux distributions, macOS, and Windows.\n- Requires the `ansible.windows` collection to be installed:\n\n  ```shell\n  ansible-galaxy collection install ansible.windows\n  ```\n- Requires the `community.general` collection to be installed:\n\n  ```shell\n  ansible-galaxy collection install community.general\n  ```\n\n### Installation\n\nInstall the [Datadog role][1] from Ansible Galaxy on your Ansible server:\n\n```shell\nansible-galaxy install datadog.datadog\n```\n\nTo deploy the Datadog Agent on hosts, add the Datadog role and your API key to your playbook:\n\n```text\n- hosts: servers\n  roles:\n    - { role: datadog.datadog, become: yes }\n  vars:\n    datadog_api_key: \"\u003cYOUR_DD_API_KEY\u003e\"\n```\n\nThe API key is required and its absence causes the role to fail. If you want to provide it through another way, outside of Ansible's control, specify a placeholder key and substitute the key at a later point.\n\n### Air-gapped environments\n\nTo install Datadog in an air-gapped environment using a specific registry and images, use the Datadog Ansible collection along with the `datadog_installer_registry`, `datadog_installer_auth`, and `agent_datadog_config` variables. \n\n**Note**: `agent_datadog_config` overrides the `installer_registry_config` setting.\n\nFor example:\n\n```yaml\nname: Datadog Agent Install\n  include_role:\n    name: datadog.dd.agent\n  vars:\n    datadog_installer_registry: \"my.local.registry\"\n    datadog_yum_repo: \"my.local.repo\"\n    datadog_api_key: \"MY_DATADOG_API_KEY\"\n    datadog_site: \"MY_DATADOG_SITE\"\n```\n\n## Role variables\n\nThese variables provide additional configuration during the installation of the Datadog Agent. They should be specified in the `vars` section of your playbook.\n\n| Variable                                    | Description                                                                                                                                                                                                                                                                                                                                                                                                                                       |\n|---------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `datadog_api_key`                           | Your Datadog API key. **This variable is mandatory starting from 4.21**.|\n| `datadog_site`                              | The site of the Datadog intake to send Agent data to. Defaults to `datadoghq.com`, set to `datadoghq.eu` to send data to the EU site. This option is only available with Agent version \u003e= 6.6.0.|\n| `datadog_agent_flavor`                      | Override the default Debian / RedHat Package for IOT Installations on RPI. Defaults to \"datadog-agent\" - use \"datadog-iot-agent\" for RPI.|\n| `datadog_agent_version`                     | The pinned version of the Agent to install (optional, but recommended), for example: `7.16.0`. Setting `datadog_agent_major_version` is not needed if `datadog_agent_version` is used.|\n| `datadog_agent_major_version`               | The major version of the Agent to install. The possible values are 6 or 7 (default). If `datadog_agent_version` is set, it takes precedence otherwise the latest version of the specified major is installed. Setting `datadog_agent_major_version` is not needed if `datadog_agent_version` is used.|\n| `datadog_checks`                            | YAML configuration for Agent checks to drop into: \u003cbr\u003e - `/etc/datadog-agent/conf.d/\u003ccheck_name\u003e.d/conf.yaml` for Agent v6 and v7.|\n| `datadog_disable_untracked_checks`          | Set to `true` to remove all checks not present in `datadog_checks` and `datadog_additional_checks`.|\n| `datadog_additional_checks`                 | List of additional checks that are not removed if `datadog_disable_untracked_checks` is set to `true`.|\n| `datadog_disable_default_checks`            | Set to `true` to remove all default checks.|\n| `datadog_config`                            | Set configuration for the Datadog Agent. The role writes the config to the [correct location based on the operating system](https://docs.datadoghq.com/agent/guide/agent-configuration-files/?tab=agentv6v7#agent-main-configuration-file). For a full list of config options, see [the `datadog.yaml` template file in the datadog-agent GitHub repository](https://github.com/DataDog/datadog-agent/blob/main/pkg/config/config_template.yaml).|\n| `datadog_config_ex`                         | (Optional) Extra INI sections to go in `/etc/dd-agent/datadog.conf` (Agent v5 only).|\n| `datadog_apt_repo`                          | Override the default Datadog `apt` repository. Make sure to use the `signed-by` option if repository metadata is signed using Datadog's signing keys: `deb [signed-by=/usr/share/keyrings/datadog-archive-keyring.gpg] https://yourrepo`.|\n| `datadog_apt_cache_valid_time`              | Override the default apt cache expiration time (defaults to 1 hour).|\n| `datadog_apt_key_url_new`                   | Override the location from which to obtain Datadog `apt` key (the deprecated `datadog_apt_key_url` variable refers to an expired key that's been removed from the role). The URL is expected to be a GPG keyring containing keys `382E94DE`, `F14F620E` and `C0962C7D`.|\n| `datadog_yum_repo_config_enabled`           | Set to `false` to prevent the configuration of a Datadog `yum` repository (defaults to `true`). WARNING: it deactivates the automatic update of GPG keys.|\n| `datadog_yum_repo`                          | Override the default Datadog `yum` repository.|\n| `datadog_yum_repo_proxy`                    | Set a proxy URL to use in the Datadog `yum` repo configuration.|\n| `datadog_yum_repo_proxy_username`           | Set a proxy username to use in the Datadog `yum` repo configuration.|\n| `datadog_yum_repo_proxy_password`           | Set a proxy password to use in the Datadog `yum` repo configuration.|\n| `datadog_yum_repo_gpgcheck`                 | Override the default `repo_gpgcheck` value (empty). If empty, value is dynamically set to `yes` when custom `datadog_yum_repo` is not used and system is not RHEL/CentOS 8.1 (due to [a bug](https://bugzilla.redhat.com/show_bug.cgi?id=1792506) in dnf), otherwise it's set to `no`. |\n| `datadog_yum_gpgcheck`                      | Override the default `gpgcheck` value (`yes`) - use `no` to turn off package GPG signature verification.|\n| `datadog_yum_gpgkey`                        | **Removed in version 4.18.0** Override the default URL to the Datadog `yum` key used to verify Agent v6 (up to 6.13) packages (key ID `4172A230`).|\n| `datadog_yum_gpgkey_e09422b3`               | Override the default URL to the Datadog `yum` key used to verify Agent v6.14+ packages (key ID `E09422B3`).|\n| `datadog_yum_gpgkey_e09422b3_sha256sum`     | Override the default checksum of the `datadog_yum_gpgkey_e09422b3` key.|\n| `datadog_zypper_repo`                       | Override the default Datadog `zypper` repository.|\n| `datadog_zypper_repo_gpgcheck`              | Override the default `repo_gpgcheck` value (empty). If empty, value is dynamically set to `yes` when custom `datadog_zypper_repo` is not used, otherwise it's set to `no`. |\n| `datadog_zypper_gpgcheck`                   | Override the default `gpgcheck` value (`yes`) - use `no` to turn off package GPG signature verification.|\n| `datadog_zypper_gpgkey`                     | **Removed in version 4.18.0** Override the default URL to the Datadog `zypper` key used to verify Agent v6 (up to 6.13) packages (key ID `4172A230`).|\n| `datadog_zypper_gpgkey_sha256sum`           | **Removed in version 4.18.0** Override the default checksum of the `datadog_zypper_gpgkey` key.|\n| `datadog_zypper_gpgkey_e09422b3`            | Override the default URL to the Datadog `zypper` key used to verify Agent v6.14+ packages (key ID `E09422B3`).|\n| `datadog_zypper_gpgkey_e09422b3_sha256sum`  | Override the default checksum of the `datadog_zypper_gpgkey_e09422b3` key.|\n| `datadog_agent_allow_downgrade`             | Set to `yes` to allow Agent downgrade (use with caution, see `defaults/main.yml` for details). **Note**: Downgrades are not supported on Windows platforms.|\n| `datadog_enabled`                           | Set to `false` to prevent `datadog-agent` service from starting (defaults to `true`).|\n| `datadog_additional_groups`                 | Either a list, or a string containing a comma-separated list of additional groups for the `datadog_user` (Linux only).|\n| `datadog_windows_ddagentuser_name`          | The name of Windows user to create/use, in the format `\u003cdomain\u003e\\\u003cuser\u003e` (Windows only).|\n| `datadog_windows_ddagentuser_password`      | The password used to create the user and/or register the service (Windows only).|\n| `datadog_apply_windows_614_fix`             | Whether or not to download and apply file referenced by `datadog_windows_614_fix_script_url` (Windows only). See https://dtdg.co/win-614-fix for more details. You can set this to `false` assuming your hosts aren't running Datadog Agent 6.14.\\*.|\n| `datadog_macos_user`                        | The name of the user to run Agent under. The user has to exist, it won't be created automatically. Defaults to `ansible_user` (macOS only).|\n| `datadog_macos_download_url`                | Override the URL to download the DMG installer from (macOS only).|\n| `datadog_apm_instrumentation_enabled`       | Configure APM instrumentation. Possible values are: \u003cbr/\u003e - `host`: Both the Agent and your services are running on a host. \u003cbr/\u003e - `docker`: The Agent and your services are running in separate Docker containers on the same host.\u003cbr/\u003e- `all`: Supports all the previous scenarios for `host` and `docker` at the same time.|\n| `datadog_apm_instrumentation_libraries`     | List of APM libraries to install if `host` or `docker` injection is enabled (defaults to `[\"java\", \"js\", \"dotnet\", \"python\", \"ruby\"]`). You can find the available values in [Inject Libraries Locally][21].|\n| `datadog_remote_updates`                    | Enable remote installation and updates through the datadog-installer.|\n\n### Integrations\n\nTo configure a Datadog integration (check), add an entry to the `datadog_checks` section. The first level key is the name of the check, and the value is the YAML payload to write the configuration file. Examples are provided below.\n\nTo install or remove an integration, refer to the `datadog_integration` [paragraph](#integration-installation)\n\n#### Process check\n\nTo define two instances for the `process` check use the configuration below. This creates the corresponding configuration files:\n\n* Agent v6 \u0026 v7: `/etc/datadog-agent/conf.d/process.d/conf.yaml`\n\n```yml\n    datadog_checks:\n      process:\n        init_config:\n        instances:\n          - name: ssh\n            search_string: ['ssh', 'sshd']\n          - name: syslog\n            search_string: ['rsyslog']\n            cpu_check_interval: 0.2\n            exact_match: true\n            ignore_denied_access: true\n```\n\n#### Custom check\n\nTo configure a custom check use the configuration below. This creates the corresponding configuration files:\n\n- Agent v6 \u0026 v7: `/etc/datadog-agent/conf.d/my_custom_check.d/conf.yaml`\n\n```yml\n    datadog_checks:\n      my_custom_check:\n        init_config:\n        instances:\n          - some_data: true\n```\n\n##### Custom Python Checks\n\nTo pass a Python check to the playbook, use the configuration below.\n\nThis configuration requires the Datadog [play and role][12] to be a part of the larger playbook where the value passed in is the relative file path to the actual task for [Linux][13] or [Windows][14].\n\nThe key should be the name of the file created in the checks directory `checks.d/{{ item }}.py`:\n\n```yml\n    datadog_checks:\n      my_custom_check:\n        init_config:\n        instances:\n          - some_data: true\n    datadog_custom_checks:\n      my_custom_check: '../../../custom_checks/my_custom_check.py'\n```\n\n#### Autodiscovery\n\nWhen using Autodiscovery, there is no pre-processing nor post-processing on the YAML. This means every YAML section is added to the final configuration file, including `autodiscovery identifiers`.\n\nThe example below configures the PostgreSQL check through **Autodiscovery**:\n\n```yml\n    datadog_checks:\n      postgres:\n        ad_identifiers:\n          - db-master\n          - db-slave\n        init_config:\n        instances:\n          - host: %%host%%\n            port: %%port%%\n            username: username\n            password: password\n```\n\nLearn more about [Autodiscovery][3] in the Datadog documentation.\n\n### Tracing\n\nTo enable trace collection with Agent v6 or v7 use the following configuration:\n\n```yaml\ndatadog_config:\n  apm_config:\n    enabled: true\n```\n\n### Live processes\n\nTo enable [live process][6] collection with Agent v6 or v7 use the following configuration:\n\n```yml\ndatadog_config:\n  process_config:\n    enabled: \"true\" # type: string\n```\n\nThe possible values for `enabled` are: `\"true\"`, `\"false\"` (only container collection), or `\"disabled\"` (disable live processes entirely).\n\n#### Variables\n\nThe following variables are available for live processes:\n\n* `scrub_args`: Enables the scrubbing of sensitive arguments from a process command line (defaults to `true`).\n* `custom_sensitive_words`: Expands the default list of sensitive words used by the command line scrubber.\n\n#### System probe\n\nThe system probe is configured under the `system_probe_config` variable. Any variables nested underneath are written to the `system-probe.yaml`, in the `system_probe_config` section.\n\n[Network Performance Monitoring][7] (NPM) is configured under the `network_config` variable. Any variables nested underneath are written to the `system-probe.yaml`, in the `network_config` section.\n\n[Cloud Workload Security][8] is configured under the `runtime_security_config` variable. Any variables nested underneath are written to the `system-probe.yaml` and `security-agent.yaml`, in the `runtime_security_config` section.\n\n[Universal Service Monitoring][17] (USM) is configured under the `service_monitoring_config` variable. Any variables nested underneath are written to the `system-probe.yaml`, in the `service_monitoring_config` section.\n\n[Compliance][18] is configured under the `compliance_config` variable. Any variables nested underneath are written to the `security-agent.yaml`, in the `compliance_config` section.\n\nAll other configuration for the system probe that does not live under any of the above keys should be configured under the `system_probe_other_config` variable. Any variables nested underneath are written to the top level\nof `system-probe.yaml`.\n\n**Note for Windows users**: NPM is supported on Windows with Agent v6.27+ and v7.27+. It ships as an optional component that is only installed if `network_config.enabled` is set to true when the Agent is installed or upgraded. Because of this, existing installations might need to do an uninstall and reinstall of the Agent once to install the NPM component, unless the Agent is upgraded at the same time.\n\n#### Example configuration\n\n```yml\ndatadog_config:\n  process_config:\n    enabled: \"true\" # type: string\n    scrub_args: true\n    custom_sensitive_words: ['consul_token','dd_api_key']\nsystem_probe_config:\n  sysprobe_socket: /opt/datadog-agent/run/sysprobe.sock\nnetwork_config:\n  enabled: true\nservice_monitoring_config:\n  enabled: true\nruntime_security_config:\n  enabled: true\nsystem_probe_other_config:\n  traceroute:\n    enabled: true\n```\n\n**Note**: This configuration works with Agent 6.24.1+ and 7.24.1+. For older Agent versions, see the [Network Performance Monitoring][9] documentation on how to enable system-probe.\n\nOn Linux, once this modification is complete, follow the steps below if you installed an Agent version older than 6.18.0 or 7.18.0:\n\n1. Start the system-probe: `sudo service datadog-agent-sysprobe start` **Note**: If the service wrapper is not available on your system, run this command instead: `sudo initctl start datadog-agent-sysprobe`.\n2. [Restart the Agent][10]: `sudo service datadog-agent restart`.\n3. Enable the system-probe to start on boot: `sudo service enable datadog-agent-sysprobe`.\n\nFor manual setup, see the [NPM][9] documentation.\n\n## Versions\n\nBy default, the current major version of the Datadog Ansible role installs Agent v7. The variables `datadog_agent_version` and `datadog_agent_major_version` are available to control the Agent version installed.\n\nFor v4+ of this role, when `datadog_agent_version` is used to pin a specific Agent version, the role derives per-OS version names to comply with the version naming schemes of the supported operating systems, for example:\n\n- `1:7.16.0-1` for Debian and SUSE based\n- `7.16.0-1` for RedHat-based\n- `7.16.0-1` for macOS\n- `7.16.0` for Windows.\n\nThis makes it possible to target hosts running different operating systems in the same Ansible run, for example:\n\n| Provided                            | Installs     | System                |\n|-------------------------------------|--------------|-----------------------|\n| `datadog_agent_version: 7.16.0`     | `1:7.16.0-1` | Debian and SUSE-based |\n| `datadog_agent_version: 7.16.0`     | `7.16.0-1`   | RedHat-based          |\n| `datadog_agent_version: 7.16.0`     | `7.16.0-1`   | macOS                 |\n| `datadog_agent_version: 7.16.0`     | `7.16.0`     | Windows               |\n| `datadog_agent_version: 1:7.16.0-1` | `1:7.16.0-1` | Debian and SUSE-based |\n| `datadog_agent_version: 1:7.16.0-1` | `7.16.0-1`   | RedHat-based          |\n| `datadog_agent_version: 1:7.16.0-1` | `7.16.0`     | Windows               |\n\n**Note**: If the version is not provided, the role uses `1` as the epoch and `1` as the release number.\n\n### Repositories\n\n#### Linux\n\nWhen the variables `datadog_apt_repo`, `datadog_yum_repo`, and `datadog_zypper_repo` are not set, the official Datadog repositories for the major version set in `datadog_agent_major_version` are used:\n\n| # | Default apt repository                    | Default yum repository             | Default zypper repository               |\n|---|-------------------------------------------|------------------------------------|-----------------------------------------|\n| 6 | deb https://apt.datadoghq.com stable 6    | https://yum.datadoghq.com/stable/6 | https://yum.datadoghq.com/suse/stable/6 |\n| 7 | deb https://apt.datadoghq.com stable 7    | https://yum.datadoghq.com/stable/7 | https://yum.datadoghq.com/suse/stable/7 |\n\nTo override the default behavior, set these variables to something else than an empty string.\n\nSince version 4.9.0, the `use_apt_backup_keyserver` variable has been removed, as APT keys are obtained from https://keys.datadoghq.com.\n\n#### Windows\n\nWhen the variable `datadog_windows_download_url` is not set, the official Windows MSI package corresponding to the `datadog_agent_major_version` is used:\n\n| Agent version | Default Windows MSI package URL                                                  |\n|---------------|----------------------------------------------------------------------------------|\n| 6             | https://s3.amazonaws.com/ddagent-windows-stable/datadog-agent-6-latest.amd64.msi |\n| 7             | https://s3.amazonaws.com/ddagent-windows-stable/datadog-agent-7-latest.amd64.msi |\n\nTo override the default behavior, set this variable to something other than an empty string.\n\n#### macOS\n\nWhen the variable `datadog_macos_download_url` is not set, the official macOS DMG package corresponding to the `datadog_agent_major_version` is used:\n\n| Agent version | Default macOS DMG package URL                                |\n|---------------|--------------------------------------------------------------|\n| 6             | https://install.datadoghq.com/datadog-agent-6-latest.dmg |\n| 7             | https://install.datadoghq.com/datadog-agent-7-latest.dmg |\n\nTo override the default behavior, set this variable to something other than an empty string.\n\n### Upgrade\n\nTo upgrade from Agent v6 to v7, use `datadog_agent_major_version: 7` to install the latest version or set `datadog_agent_version` to a specific version of Agent v7. Use similar logic to upgrade from Agent v5 to v6.\n\n#### Integration installation\n\n**Available for Agent v6.8+**\n\nUse the `datadog_integration` resource to install a specific version of a Datadog integration. Keep in mind, the Agent comes with the [core integrations][19] already installed. This command is useful for upgrading a specific integration without upgrading the whole Agent. For more details, see [integration management][4].\n\nIf you want to configure an integration, refer to the `datadog_checks` [paragraph](#integrations)\n\nAvailable actions:\n\n- `install`: Installs a specific version of the integration.\n- `remove`: Removes an integration.\n\n##### Third party integrations\n\n[Datadog community][20] and [Datadog Marketplace][15] integrations can be installed with the `datadog_integration` resource. **Note**: These integrations are considered to be \"third party\" and thus need `third_party: true` to be set—see the example below.\n\n##### Syntax\n\n```yml\n  datadog_integration:\n    \u003cINTEGRATION_NAME\u003e:\n      action: \u003cACTION\u003e\n      version: \u003cVERSION_TO_INSTALL\u003e\n```\n\nTo install third party integrations, set `third_party` to true:\n\n```yml\n  datadog_integration:\n    \u003cINTEGRATION_NAME\u003e:\n      action: \u003cACTION\u003e\n      version: \u003cVERSION_TO_INSTALL\u003e\n      third_party: true\n```\n\n##### Example\n\nThis example installs version `1.11.0` of the ElasticSearch integration and removes the `postgres` integration.\n\n```yml\n datadog_integration:\n   datadog-elastic:\n     action: install\n     version: 1.11.0\n   datadog-postgres:\n     action: remove\n```\n\nTo see the available versions of Datadog integrations, see their `CHANGELOG.md` file in the [integrations-core repository][5].\n\n### Downgrade\n\nTo downgrade to a prior version of the Agent:\n\n1. Set `datadog_agent_version` to a specific version, for example: `5.32.5`.\n2. Set `datadog_agent_allow_downgrade` to `yes`.\n\n**Notes:**\n\n- Downgrades are not supported for Windows platforms.\n\n## Playbooks\n\nBelow are some sample playbooks to assist you with using the Datadog Ansible role.\n\nThe following example sends data to Datadog US (default), enables logs, NPM, and configures a few checks.\n\n```yml\n- hosts: servers\n  roles:\n    - { role: datadog.datadog, become: yes }\n  vars:\n    datadog_api_key: \"\u003cYOUR_DD_API_KEY\u003e\"\n    datadog_agent_version: \"7.16.0\"\n    datadog_config:\n      tags:\n        - \"\u003cKEY\u003e:\u003cVALUE\u003e\"\n        - \"\u003cKEY\u003e:\u003cVALUE\u003e\"\n      log_level: INFO\n      apm_config:\n        enabled: true\n      logs_enabled: true  # available with Agent v6 and v7\n    datadog_checks:\n      process:\n        init_config:\n        instances:\n          - name: ssh\n            search_string: ['ssh', 'sshd' ]\n          - name: syslog\n            search_string: ['rsyslog' ]\n            cpu_check_interval: 0.2\n            exact_match: true\n            ignore_denied_access: true\n      ssh_check:\n        init_config:\n        instances:\n          - host: localhost\n            port: 22\n            username: root\n            password: \u003cYOUR_PASSWORD\u003e\n            sftp_check: True\n            private_key_file:\n            add_missing_keys: True\n      nginx:\n        init_config:\n        instances:\n          - nginx_status_url: http://example.com/nginx_status/\n            tags:\n              - \"source:nginx\"\n              - \"instance:foo\"\n          - nginx_status_url: http://example2.com:1234/nginx_status/\n            tags:\n              - \"source:nginx\"\n              - \"\u003cKEY\u003e:\u003cVALUE\u003e\"\n\n        #Log collection is available on Agent 6 and 7\n        logs:\n          - type: file\n            path: /var/log/access.log\n            service: myapp\n            source: nginx\n            sourcecategory: http_web_access\n          - type: file\n            path: /var/log/error.log\n            service: nginx\n            source: nginx\n            sourcecategory: http_web_access\n    # datadog_integration is available on Agent 6.8+\n    datadog_integration:\n      datadog-elastic:\n        action: install\n        version: 1.11.0\n      datadog-postgres:\n        action: remove\n    network_config:\n      enabled: true\n```\n\n### Agent v6\n\nThis example installs the latest Agent v6:\n\n```yml\n- hosts: servers\n  roles:\n    - { role: datadog.datadog, become: yes }\n  vars:\n    datadog_agent_major_version: 6\n    datadog_api_key: \"\u003cYOUR_DD_API_KEY\u003e\"\n```\n\n### Configuring the site\n\nIf using a site other than the default `datadoghq.com`, set the `datadog_site` var to the appropriate URL (eg: `datadoghq.eu`,  `us3.datadoghq.com`).\n\nThis example sends data to the EU site:\n\n```yml\n- hosts: servers\n  roles:\n    - { role: datadog.datadog, become: yes }\n  vars:\n    datadog_site: \"datadoghq.eu\"\n    datadog_api_key: \"\u003cYOUR_DD_API_KEY\u003e\"\n```\n\n### Windows\n\nOn Windows, remove the `become: yes` option so the role does not fail. Below are two methods to make the example playbooks work with Windows hosts:\n\n#### Inventory file\n\nUsing the inventory file is the recommended approach. Set the `ansible_become` option to `no` in the inventory file for each Windows host:\n\n```ini\n[servers]\nlinux1 ansible_host=127.0.0.1\nlinux2 ansible_host=127.0.0.2\nwindows1 ansible_host=127.0.0.3 ansible_become=no\nwindows2 ansible_host=127.0.0.4 ansible_become=no\n```\n\nTo avoid repeating the same configuration for all Windows hosts, group them and set the variable at the group level:\n\n```ini\n[linux]\nlinux1 ansible_host=127.0.0.1\nlinux2 ansible_host=127.0.0.2\n\n[windows]\nwindows1 ansible_host=127.0.0.3\nwindows2 ansible_host=127.0.0.4\n\n[windows:vars]\nansible_become=no\n```\n\n#### Playbook file\n\nAlternatively, if your playbook **only runs on Windows hosts**, use the following in the playbook file:\n\n```yml\n- hosts: servers\n  roles:\n    - { role: datadog.datadog }\n  vars:\n    ...\n```\n\n**Note**: This configuration fails on Linux hosts. Only use it if the playbook is specific to Windows hosts. Otherwise, use the [inventory file method](#inventory-file).\n\n### Uninstallation\n\nOn Windows it's possible to uninstall the Agent by using the following code in your Ansible role:\n\n```yml\n- name: Check If Datadog Agent is installed\n  win_shell: |\n    (@(Get-ChildItem -Path \"HKLM:SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\" -Recurse) | Where {$_.GetValue(\"DisplayName\") -like \"Datadog Agent\" }).PSChildName\n  register: agent_installed_result\n- name: Set Datadog Agent installed fact\n  set_fact:\n    agent_installed: \"{{ agent_installed_result.stdout | trim }}\"\n- name: Uninstall the Datadog Agent\n  win_package:\n    product_id: \"{{ agent_installed }}\"\n    state: absent\n  when: agent_installed != \"\"\n```\n\n## Troubleshooting\n\n### Debian stretch\n\n**Note:** this information applies to versions of the role prior to 4.9.0. Since 4.9.0, the `apt_key` module is no longer used by the role.\n\nOn Debian Stretch, the `apt_key` module used by the role requires an additional system dependency to work correctly. The dependency (`dirmngr`) is not provided by the module. Add the following configuration to your playbooks to make use of the present role:\n\n```yml\n---\n- hosts: all\n  pre_tasks:\n    - name: Debian Stretch requires the dirmngr package to use apt_key\n      become: yes\n      apt:\n        name: dirmngr\n        state: present\n  roles:\n    - { role: datadog.datadog, become: yes }\n  vars:\n    datadog_api_key: \"\u003cYOUR_DD_API_KEY\u003e\"\n```\n\n### CentOS 6/7 with Python 3 interpreter and Ansible 2.10.x or below\n\n**DEPRECATED: This section only applies to Ansible role versions 4 or below. Starting with version 5, this role no longer supports CentOS 6/7 and requires Ansible Core 2.10 or higher.**\n\nThe `yum` Python module, which is used in this role to install the Agent on CentOS-based hosts, is only available on Python 2 if Ansible 2.10.x or below is used. In such cases, the `dnf` package manager would have to be used instead.\n\nHowever, `dnf` and the `dnf` Python module are not installed by default on CentOS-based hosts before CentOS 8. In this case, it is not possible to install the Agent when a Python 3 interpreter is used.\n\nThis role fails early when this situation is detected to indicate that Ansible 2.11+ or a Python 2 interpreter is needed when installing the Agent on CentOS / RHEL \u003c 8.\n\nTo bypass this early failure detection (for instance, if `dnf` and the `python3-dnf` package are available on your host), set the `datadog_ignore_old_centos_python3_error` variable to `true`.\n\n### Windows\n\nDue to a critical bug in Agent versions `6.14.0` and `6.14.1` on Windows, installation of these versions is blocked (starting with version `3.3.0` of this role).\n\n**NOTE:** Ansible fails on Windows if `datadog_agent_version` is set to `6.14.0` or `6.14.1`. Use `6.14.2` or above.\n\nIf you are updating from **6.14.0 or 6.14.1 on Windows**, use the following steps:\n\n1. Upgrade the present `datadog.datadog` Ansible role to the latest version (`\u003e=3.3.0`).\n2. Set the `datadog_agent_version` to `6.14.2` or above (defaults to latest).\n\nFor more details, see [Critical Bug in Uninstaller for Datadog Agent 6.14.0 and 6.14.1 on Windows][11].\n\n### Ubuntu 20.04 broken by service_facts\n\nRunning the `service_facts` module on Ubuntu 20.04 causes the following error:\n\n```\nlocalhost | FAILED! =\u003e {\n    \"changed\": false,\n    \"msg\": \"Malformed output discovered from systemd list-unit-files: accounts-daemon.service                    enabled         enabled      \"\n}\n```\n\nTo fix this, [update Ansible to `v2.9.8` or above][16].\n\n### Missing API key\n\nStarting from role `4.21` the API key is mandatory for the role to proceed.\n\nIf you need to install the agent through Ansible but don't want to specify an API key (if you are baking it into a container/VM image for instance) you can:\n* Specify a dummy API key and replace it afterward\n* Disable managed_config (`datadog_manage_config: false`)\n\n[1]: https://galaxy.ansible.com/ui/standalone/roles/DataDog/datadog/\n[2]: https://github.com/DataDog/ansible-datadog\n[3]: https://docs.datadoghq.com/agent/autodiscovery\n[4]: https://docs.datadoghq.com/agent/guide/integration-management/\n[5]: https://github.com/DataDog/integrations-core\n[6]: https://docs.datadoghq.com/infrastructure/process/\n[7]: https://docs.datadoghq.com/network_performance_monitoring/\n[8]: https://docs.datadoghq.com/security_platform/cloud_workload_security/getting_started/\n[9]: https://docs.datadoghq.com/network_performance_monitoring/installation/?tab=agent#setup\n[10]: https://docs.datadoghq.com/agent/guide/agent-commands/#restart-the-agent\n[11]: https://app.datadoghq.com/help/agent_fix\n[12]: https://docs.ansible.com/ansible/latest/reference_appendices/playbooks_keywords.html#playbook-keywords\n[13]: https://github.com/DataDog/ansible-datadog/blob/main/tasks/agent-linux.yml\n[14]: https://github.com/DataDog/ansible-datadog/blob/main/tasks/agent-win.yml\n[15]: https://www.datadoghq.com/blog/datadog-marketplace/\n[16]: https://github.com/ansible/ansible/blob/stable-2.9/changelogs/CHANGELOG-v2.9.rst#id61\n[17]: https://docs.datadoghq.com/tracing/universal_service_monitoring/?tab=configurationfiles#enabling-universal-service-monitoring\n[18]: https://docs.datadoghq.com/security/cspm/setup/?tab=docker\n[19]: https://github.com/DataDog/integrations-core\n[20]: https://github.com/DataDog/integrations-extras\n[21]: https://docs.datadog.com/tracing/trace_collection/library_injection_local\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdatadog%2Fansible-datadog","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdatadog%2Fansible-datadog","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdatadog%2Fansible-datadog/lists"}