Ce module installe l’Agent Datadog et envoie les rapports Puppet à Datadog.

Prérequis

Le module Puppet Datadog est pris en charge sur Linux et Windows et est compatible avec la version 4.6 ou une version ultérieure de Puppet, ou avec la version 2016.4 ou une version ultérieure de Puppet Enterprise. Pour obtenir des informations détaillées sur la compatibilité, consultez la page du module sur Puppet Forge (en anglais).

Installation

Installez le module Puppet agent_datadog dans le chemin du module de votre master Puppet :

puppet module install datadog-datadog_agent

Mise à niveau

• Par défaut, la version 7.x de l’Agent Datadog est installée. Pour utiliser une version antérieure de l’Agent, modifiez le paramètre agent_major_version.
• Le paramètre agent5_enable n’est plus utilisé. Il a été remplacé par agent_major_version.
• Le paramètre agent6_extra_options a été remplacé par agent_extra_options, car il concerne les versions 6 et 7 de l’Agent.
• Le paramètre agent6_log_file a été remplacé par agent_log_file, car il concerne les versions 6 et 7 de l’Agent.
• Les paramètres agent5_repo_uri et agent6_repo_uri ont été remplacés par le paramètre agent_repo_uri pour toutes les versions de l’Agent.
• Les paramètres conf_dir et conf6_dir ont été remplacés par le paramètre conf_dir pour toutes les versions de l’Agent.
• Le nom du fichier de répertoire créé sur Linux, qui était auparavant datadog5 ou datadog6, est désormais datadog.

Configuration

Une fois le module datadog_agent installé sur votre puppetserver ou puppetmaster (ou sur un host sans master), suivez les étapes de configuration ci-dessous :

1. Obtenez votre clé d’API Datadog.

2. Ajoutez la classe Datadog à vos manifestes de nœud (ex. : /etc/puppetlabs/code/environments/production/manifests/site.pp).

   class { 'datadog_agent':
       api_key => "<YOUR_DD_API_KEY>",
   }
   

   Si vous utilisez un site Datadog différent de celui par défaut (datadoghq.com), définissez-le ici également :

   class { 'datadog_agent':
       api_key => "<YOUR_DD_API_KEY>",
       datadog_site => "datadoghq.eu",
   }
   

   Pour les versions de CentOS/RHEL antérieures à 7.0 et les versions d’Ubuntu antérieures à 15.04, définissez le prestataire de services sur upstart :

   class { 'datadog_agent':
       api_key => "<YOUR_DD_API_KEY>",
       service_provider => 'upstart'
   }
   

   Consultez la section Variables de configuration pour obtenir la liste des arguments utilisables ici.

3. (Facultatif) Ajoutez les intégrations à utiliser avec l’Agent. Dans l’exemple suivant, l’intégration Mongo est installée :

   class { 'datadog_agent::integrations::mongo':
       # integration arguments go here
   }
   

   Référez-vous aux commentaires dans le code pour obtenir la liste de tous les arguments disponibles pour une intégration donnée.

   Si une intégration ne dispose pas d’un manifeste avec une classe dédiée, vous pouvez toujours ajouter une configuration pour celle-ci. Voici un exemple pour le check ntp :

   class { 'datadog_agent':
       api_key      => "<YOUR_DD_API_KEY>",
       integrations => {
           "ntp" => {
               init_config => {},
               instances => [{
                   offset_threshold => 30,
               }],
           },
       },
   }
   

4. (Facultatif) Pour recueillir des métriques et des événements liés au service Puppet, consultez la section Rapports.

Mettre à jour une intégration

Pour installer et imposer une version spécifique d’une intégration, utilisez datadog_agent::install_integration. La commande datadog-agent integration est alors appelée pour s’assurer qu’une intégration spécifique est installée ou désinstallée. Exemple :

datadog_agent::install_integration { "mongo-1.9":
    ensure => present,
    integration_name => 'datadog-mongo',
    version => '1.9.0',
    third_party => false,
}

L’argument ensure accepte deux valeurs :

• present (valeur par défaut)
• absent (supprime une version préalablement imposée d’une intégration)

Pour installer une intégration tierce (par exemple depuis le Marketplace), définissez l’argument third_party sur true.

Notez qu’il est possible d’installer une version plus ancienne d’une intégration que cette intégrée à l’Agent.

Rapports

Pour activer l’envoi de rapports sur les exécutions Puppet vers votre flux Datadog, activez le processeur de rapports sur votre master Puppet et l’envoi de rapports pour vos clients. Les clients renvoient au master un rapport d’exécution après chaque vérification.

1. Installez le gem dogapi sur votre système. Redémarrez puppetserver une fois le gem installé.

Pour configurer dogapi au sein de votre code, utilisez notify :

package { 'dogapi':
  ensure   => 'present',
  provider => 'puppetserver_gem',
  notify   => Service['puppetserver']
}

2. Définissez l’option puppet_run_reports sur true dans le manifeste de configuration des nœuds pour votre master :

   class { 'datadog-agent':
     api_key            => '<YOUR_DD_API_KEY>',
     puppet_run_reports => true
     # ...
   }
   

3. Ajoutez ces options de configuration à la configuration du master Puppet (ex. : /etc/puppetlabs/puppet/puppet.conf) :

   [main]
   # No modification needed to this section
   # ...
   
   [master]
   # Enable reporting to Datadog
   reports=datadog_reports
   # If you use other reports, add datadog_reports to the end,
   # for example: reports=store,log,datadog_reports
   # ...
   
   [agent]
   # ...
   report=true
   

Avec le module ini_setting :

  ini_setting { 'puppet_conf_master_report_datadog_puppetdb':
    ensure  => present,
    path    => '/etc/puppetlabs/puppet/puppet.conf',
    section => 'master',
    setting => 'reports',
    value   => 'datadog_reports,puppetdb',
    notify  => [
      Service['puppet'],
      Service['puppetserver'],
    ],
  }

4. Sur tous vos nœuds client Puppet, ajoutez ce qui suit au même emplacement :

   [agent]
   # ...
   report=true
   

Avec le module ini_setting :

  ini_setting { 'puppet_conf_agent_report_true':
    ensure  => present,
    path    => '/etc/puppetlabs/puppet/puppet.conf',
    section => 'agent',
    setting => 'report',
    value   => 'true',
    notify  => [
      Service['puppet'],
    ],
  }

5. (Facultatif) Activez le tagging des rapports avec des faits :

   Vous pouvez ajouter des tags aux rapports qui sont envoyés à Datadog sous la forme d’événements. Ces tags peuvent provenir de faits Puppet propres au nœud sur lequel porte le rapport. Ils doivent être individuels et ne pas comprendre de faits structurés (hashs, tableaux, etc.) pour garantir la lisibilité. Pour activer le tagging des faits standard, définissez le paramètre datadog_agent::reports::report_fact_tags sur la valeur de tableau des faits, par exemple ["virtual","operatingsystem"]. Pour activer le tagging des faits de confiance, définissez le paramètre datadog_agent::reports::report_trusted_fact_tags sur la valeur de tableau des faits, par exemple ["certname","extensions.pp_role","hostname"].

   Remarque : la modification de ces paramètres nécessite un redémarrage de pe-puppetserver (ou de puppetserver) pour lancer une relecture du processeur de rapports. Assurez-vous que les changements sont déployés avant de redémarrer le(s) service(s).

   Conseils :

   • Utilisez une notation par points pour spécifier un fait cible ; sinon, l’ensemble des données de fait devient la valeur sous forme de chaîne (peu utile)
   • Ne dupliquez pas les données de surveillance courantes comme le nom de l’host, l’uptime, la mémoire, etc.
   • Coordonnez les faits essentiels comme le rôle, le propriétaire, le modèle, le centre de données, etc. pour établir des corrélations pertinentes avec les mêmes tags à partir de métriques

6. Vérifiez que vos données Puppet se trouvent dans Datadog en recherchant sources:puppet dans le flux d’événements.

Dépannage

Vous pouvez exécuter l’Agent Puppet manuellement pour vérifier la présence d’erreurs dans la sortie :

```shell
sudo systemctl restart puppetserver
sudo puppet agent --onetime --no-daemonize --no-splay --verbose
```

 Example response:

```text
info: Retrieving plugin
info: Caching catalog for alq-linux.dev.datadoghq.com
info: Applying configuration version '1333470114'
notice: Finished catalog run in 0.81 seconds
```

Si vous constatez l’erreur suivante, assurez-vous que reports=datadog_reports est défini dans [master], et non dans [main].

```text
err: Could not send report:
Error 400 on SERVER: Could not autoload datadog_reports:
Class Datadog_reports is already defined in Puppet::Reports
```

Si vous ne recevez aucun rapport, consultez les logs de votre serveur Puppet.

Puppet sans master

1. Le module Datadog et ses dépendances doivent être installés sur tous les nœuds exécutés sans master.

2. Ajoutez ce qui suit au fichier site.pp de chaque nœud :

   class { "datadog_agent":
       api_key            => "<YOUR_DD_API_KEY>",
       puppet_run_reports => true
   }
   

3. Exécutez Puppet avec une configuration sans master :

   puppet apply --modulepath <path_to_modules> <path_to_site.pp>
   

Tagging des nœuds client

Le fichier de configuration de l’Agent Datadog est recréé à partir du modèle à chaque exécution de Puppet. Si vous devez taguer vos nœuds, ajoutez une entrée de tableau dans Hiera :

datadog_agent::tags:
- 'keyname:value'
- 'anotherkey:%{factname}'

Pour générer des tags à partir de faits personnalisés, classez vos nœuds en spécifiant les faits Puppet sous forme de tableau associé au paramètrefacts_to_tags, soit via la console Puppet Enterprise, soit via Hiera. Voici un exemple :

class { "datadog_agent":
  api_key            => "<VOTRE_CLÉ_API_DD>",
  facts_to_tags      => ["osfamily","networking.domain","my_custom_fact"],
}

Conseils :

1. Pour les faits structurés, effectuez l’indexation dans la valeur de fait spécifique ; sinon, le tableau entier est défini comme une chaîne, ce qui rend son utilisation difficile.
2. Les faits dynamiques tels que la charge processeur ou encore la disponibilité changent généralement à chaque exécution, et ne sont donc pas conseillés pour le tagging. À l’inverse, les faits statiques restent généralement identiques pendant toute la durée de vie d’un nœud. Ils sont donc parfaitement adaptés pour le tagging.

Variables de configuration

Ces variables peuvent être définies dans la classe datadog_agent afin de contrôler les paramètres de l’Agent. Consultez les commentaires dans le code pour obtenir la liste de tous les arguments disponibles.

(1) La variable agent_extra_options est utilisée pour contrôler précisément des options de configuration supplémentaires de l’Agent v6 ou v7. Le deep merge effectué est susceptible de remplacer les options des paramètres de la classe datadog_agent. Exemple :

class { "datadog_agent":
    < vos autres arguments de la classe >,
    agent_extra_options => {
        use_http => true,
        use_compression => true,
        compression_level => 6,
    },
}

(2) La variable hostname_extraction_regex s’avère utile lorsque le module Puppet et l’Agent Datadog transmettent des hostnames différents pour un même host dans la liste d’infrastructures.