Références pour les ressources d'intégration

Fichier de configuration

Lorsque vous préparez une nouvelle intégration, vous devez inclure un exemple de configuration contenant les options requises et des valeurs par défaut appropriées. L’exemple de fichier de configuration, ici situé dans <NOM_CHECK>/datadog_checks/<NOM_CHECK>/data/conf.yaml.example, comprend deux éléments de premier niveau : init_config et instances. La configuration sous init_config est appliquée à l’ensemble de l’intégration et utilisée à chaque instanciation de l’intégration, tandis que ce qui trouve sous instances est spécifique à une instanciation donnée.

Les blocs de configuration sous chaque section prennent le format suivant :

## @<COMMANDE> [- <ARGUMENTS>]
## <LIGNE DESCRIPTION 1>
## <LIGNE DESCRIPTION 2>
#
<KEY>: <VALUE>

Les blocs de configuration doivent respecter quelques principes :

• La description ne doit pas être vide.
• Les placeholders doivent toujours respecter ce format : <CECI_EST_UN_PLACEHOLDER>, conformément aux règles de contribution à la documentation.
• Par défaut, tous les paramètres requis ne sont pas mis en commentaire.
• Par défaut, tous les paramètres facultatifs sont mis en commentaire.
• Si un placeholder présente une valeur par défaut pour une intégration (comme l’endpoint de statut d’une intégration), celle-ci peut être utilisée à la place d’un placeholder générique.

Spécification @param

En pratique, la seule commande est @param, qui est utilisée pour décrire les blocs de configuration, principalement à des fins de documentation. @param doit être implémentée en respectant l’un des formats suivants :

@param <nom> - <type> - requis
@param <nom> - <type> - facultatif
@param <nom> - <type> - facultatif - valeur par défaut : <valeur_defaut>

Arguments :

• nom : le nom du paramètre, par exemple search_string (obligatoire).
• type : le type de données de la valeur du paramètre (obligatoire). Valeurs autorisées :
  • boolean
  • string
  • Nombre entier
  • double
  • float
  • dictionary
  • list*
  • object
• valeur_defaut : la valeur par défaut pour le paramètre ; peut être laissé vide (facultatif).

Les variables list et object couvrent plusieurs lignes et font l’objet de règles spéciales.

• Dans une list, les éléments individuels ne sont pas documentés via la spécification @param
• Dans un object, vous avez la possibilité de documenter les éléments individuellement avec la spécification @param ou de spécifier une description commune au niveau supérieur juste après la spécification de l’objet.

Paramètres facultatifs

Un paramètre facultatif doit être mis en commentaire par défaut. Au début de chaque ligne couverte par le paramètre, ajoutez # en appliquant la même indentation que pour la spécification @param.

Commentaires de bloc

Vous pouvez ajouter un commentaire de bloc n’importe où dans le fichier de configuration. Les règles suivantes doivent être appliquées :

• Les commentaires commencent par ##
• Les commentaires doivent être indentés comme les variables (le trait d’union ne compte pas).

Pour en savoir plus sur la syntaxe YAML, consultez l’article Wikipedia. Et n’hésitez pas à faire bon usage du parser en ligne Online YAML Parser !

Fichier manifest

Chaque intégration contient un fichier manifest.json qui décrit les paramètres de fonctionnement de l’intégration, sa place dans l’écosystème d’intégrations global de Datadog, et d’autres informations semblables.

Il existe deux versions du fichier manifest.json. Bien que la version 1 du manifeste soit toujours prise en charge par les intégrations existantes, toutes les nouvelles intégrations, à savoir les Apps Datadog et les offres du Marketplace, doivent utiliser la version 2 du manifeste.

Si la ligne suivante figure en haut de votre fichier manifest.json, cela signifie qu’il s’agit de la version 2 :

"manifest_version": "2.0.0"

Si ce n’est pas le cas, vous utilisez la version 1 du manifeste.

Ces deux versions proposent différents attributs et différentes structures. Le tableau ci-dessous répertorie tous les attributs obligatoires et facultatifs des deux versions du fichier manifest.json :

Fichier service_check

Le fichier service_check.json décrit les checks de service effectués par l’intégration.

Le fichier service_checks.json contient les attributs obligatoires suivants :

Fichier metadata des métriques

Le fichier metadata.csv décrit toutes les métriques pouvant être recueillies par l’intégration.

Description de chaque colonne du fichier metadata.csv :