intégration sur hôte : format configuration existant

L'intégration de New Relic Infrastructure sur hôte peut utiliser l'un des deux types de formatsconfiguration . Ce document explique l'ancienlegacy configuration format .

Important

New Relic recommande d'utiliser le nouveau format de configuration standard amélioré. Pour mettre à jour votre fichier de configuration vers ce nouveau format, consultez la section de mise à jour

Pour une introduction à la configuration, voir Présentation de la configuration.

Structure du fichier de configuration

Une intégration sur hôte qui utilise le format de configuration standard nécessite deux fichiers de configuration :

Un fichier de définition
Un fichier de configuration

Fichier de définition

Le fichier de définition a un format de nommage tel que INTEGRATION_NAME-definition.yml. Ce fichier fournit des informations descriptives sur l'intégration, telles que : la version du protocole JSON qu'il prend en charge, une liste des commandes qu'il peut exécuter et les arguments qu'il accepte. Il se trouve dans ce répertoire :

Linux:
```
/var/db/newrelic-infra/newrelic-integrations
```

Windows:

C:\Program Files\New Relic\newrelic-infra\newrelic-integrations

Voici un exemple de fichier de définition d’intégration NGINX avec deux sections de commande sur un système Linux :

name: com.myorg.nginx
protocol_version: 2
description: Collect metric and configuration data from NGINX
os: linux
commands:
  metrics:
    command:
      - myorg-nginx
      - --metrics
    interval: 15
  inventory:
    command:
      - myorg-nginx
      - --inventory
    interval: 120
    prefix: integration/myorg-nginx

Un fichier de définition peut être divisé en deux parties :

L'en-tête
La section des commandes

En-tête du fichier de définition

Voici les explications des éléments d'en-tête d'un fichier de définition :

Champ d'en-tête de définition	Description
`name`	Requis. Un nom unique `name` pour identifier l'intégration pour le logging, les métriques internes, etc. Lorsque l'agent charge le fichier de configuration, New Relic utilise `name` pour rechercher l'intégration dans le registre de l'agent.
`protocol_version`	Requis. Le numéro de version du protocole. New Relic utilise cela pour garantir la compatibilité entre l'intégration et l'agent. Si l'agent ne reconnaît pas la version d'une intégration, il filtrera cette intégration et créera un message de log. La version actuelle du protocole JSON est `2`. Pour en savoir plus sur les modifications du protocole, consultez Modifications du SDK.
`description`	Facultatif. Explication conviviale de ce que fait l’intégration.
`os`	Facultatif. Le système d’exploitation sur lequel l’intégration s’exécute. New Relic utilise cela pour filtrer l'intégration que vous souhaitez exécuter uniquement sur un système d'exploitation spécifique. Par défaut : exécutez l’intégration quelle que soit la valeur `os` . Pour restreindre l’intégration à un système d’exploitation spécifique, utilisez l’une de ces options : `linux` `windows`

Commandes du fichier de définition

Après l'en-tête se trouve une liste de commandes. La section commandes définit :

Un ou plusieurs modes de fonctionnement indépendants pour l'exécutable
Les données d'exécution nécessaires à son exécution

La section des commandes est une carte YAML des définitions de commandes, où chaque clé est le nom d'alias unique de la commande dans le fichier de configuration de l'intégration qui spécifie l'exécutable à exécuter.

Définition des commandes	Description
`command`	Requis. La ligne de commande réelle à exécuter sous la forme d'un éventail YAML de parties de commande. Ceux-ci sont assemblés pour exécuter la commande réelle. Pour les commandes simples, l'éventail peut être constitué d'un seul élément. Les règles de commande supplémentaires incluent : `command` arguments : La commande et tous les arguments de ligne de commande qui sont partagés pour toutes les instances de la configuration d'intégration. `command` exécution : La commande sera exécutée dans le même répertoire que le fichier de définition. `command` chemin : toutes les commandes disponibles sur le `$PATH` de l'hôte peuvent être utilisées. Les exécutables situés dans le même répertoire que le fichier de définition, ou dans un sous-répertoire de celui-ci, peuvent être exécutés à l'aide d'un chemin relatif. Par exemple: Linux: Pour exécuter un exécutable appelé `myorg-nginx` dans le même répertoire que le fichier de définition, vous pouvez utiliser `myorg-nginx` ou `./myorg-nginx`. Le système Linux exécutera `myorg-nginx` comme si l'utilisateur utilisait `./myorg-nginx`. Windows: Pour exécuter un exécutable appelé `myorg-nginx.exe` dans le même répertoire que le fichier de définition, vous pouvez utiliser `\myorg-nginx.exe` ou `.\myorg-nginx.exe`. L'écriture système Windows `myorg-nginx.exe` sera exécutée comme si elle indiquait le chemin actuel : `.\myorg-nginx.exe`. Pour utiliser une commande installée dans un répertoire sur le `$PATH` de l'hôte, utilisez simplement le nom de la commande. Exemple : `python`. Pour exécuter tout autre exécutable qui ne se trouve ni sur le `$PATH` de l'hôte ni dans le répertoire de l'intégration, utilisez un chemin absolu vers l'exécutable. Exemple : `/opt/jdk/bin/java`. Si le nom exécutable donné existe dans le répertoire de l'intégration mais existe également ailleurs sur le système `$PATH`, la version dans le répertoire de l'intégration est prioritaire.
`interval`	Facultatif. Le nombre de secondes entre deux exécutions consécutives de la commande, notamment entre la fin de l'exécution précédente et le début de l'exécution suivante. Par défaut pour l'interrogation métrique : 30 secondes. Minimum (plancher) : 15 secondes. Alertes : pour les mesures utilisées pour les alertes, utilisez un intervalle de 30 secondes ou moins.
`prefix`	Facultatif. La catégorisation de l'inventaire sous la forme de `category/short_integration_name`. Exemple : `integration/myorg-nginx`. Le préfixe n'est pas un chemin spécifique à la plateforme. La barre oblique est le séparateur correct entre la catégorie et `short_integration_name`. Le préfixe peut avoir un maximum de deux niveaux. Dans le cas contraire, l’inventaire ne sera pas signalé. Valeur par défaut si non définie : `integration/integration_name`.

Définition des commandes

Description

command

Requis. La ligne de commande réelle à exécuter sous la forme d'un éventail YAML de parties de commande. Ceux-ci sont assemblés pour exécuter la commande réelle. Pour les commandes simples, l'éventail peut être constitué d'un seul élément.

Les règles de commande supplémentaires incluent :

command arguments : La commande et tous les arguments de ligne de commande qui sont partagés pour toutes les instances de la configuration d'intégration.
command exécution : La commande sera exécutée dans le même répertoire que le fichier de définition.
command chemin : toutes les commandes disponibles sur le $PATH de l'hôte peuvent être utilisées. Les exécutables situés dans le même répertoire que le fichier de définition, ou dans un sous-répertoire de celui-ci, peuvent être exécutés à l'aide d'un chemin relatif. Par exemple:
- Linux: Pour exécuter un exécutable appelé myorg-nginx dans le même répertoire que le fichier de définition, vous pouvez utiliser myorg-nginx ou ./myorg-nginx. Le système Linux exécutera myorg-nginx comme si l'utilisateur utilisait ./myorg-nginx.
- Windows: Pour exécuter un exécutable appelé myorg-nginx.exe dans le même répertoire que le fichier de définition, vous pouvez utiliser \myorg-nginx.exe ou .\myorg-nginx.exe. L'écriture système Windows myorg-nginx.exe sera exécutée comme si elle indiquait le chemin actuel : .\myorg-nginx.exe.
- Pour utiliser une commande installée dans un répertoire sur le $PATH de l'hôte, utilisez simplement le nom de la commande. Exemple : python.
- Pour exécuter tout autre exécutable qui ne se trouve ni sur le $PATH de l'hôte ni dans le répertoire de l'intégration, utilisez un chemin absolu vers l'exécutable. Exemple : /opt/jdk/bin/java.
Si le nom exécutable donné existe dans le répertoire de l'intégration mais existe également ailleurs sur le système $PATH, la version dans le répertoire de l'intégration est prioritaire.

interval

Facultatif. Le nombre de secondes entre deux exécutions consécutives de la commande, notamment entre la fin de l'exécution précédente et le début de l'exécution suivante.

Par défaut pour l'interrogation métrique : 30 secondes.
Minimum (plancher) : 15 secondes.
Alertes : pour les mesures utilisées pour les alertes, utilisez un intervalle de 30 secondes ou moins.

prefix

Facultatif. La catégorisation de l'inventaire sous la forme de category/short_integration_name. Exemple : integration/myorg-nginx.

Le préfixe n'est pas un chemin spécifique à la plateforme. La barre oblique est le séparateur correct entre la catégorie et short_integration_name.

Le préfixe peut avoir un maximum de deux niveaux. Dans le cas contraire, l’inventaire ne sera pas signalé.

Valeur par défaut si non définie : integration/integration_name.

Fichier de configuration

Le fichier de configuration a un format de nommage tel que INTEGRATION_NAME-config.yml. Ce fichier spécifie les exécutables à exécuter et les paramètres requis pour les exécuter. Il se trouve dans ce répertoire :

Linux:
```
/etc/newrelic-infra/integrations.d/
```

Windows:

C:\Program Files\New Relic\newrelic-infra\integrations.d

Conseil

Nous vous recommandons de vérifier les fichiers de configuration YAML avant de les utiliser pour éviter les problèmes de formatage.

Voici un exemple de fichier de configuration avec une instance définie. Les explications de ces champs sont expliquées sous l'exemple.

integration_name: com.myorg.nginx
instances:
  - name: nginx1.myorg.com-metrics
    command: metrics
    arguments:
      status_url: http://127.0.0.1/status
    labels:
      environment: production
      role: load_balancer

Un autre exemple d'un fichier de configuration avec deux instances définies.

integration_name: com.myorg.nginx
instances:
  - name: nginx1.myorg.com-metrics
    command: metrics
    arguments:
      status_url: http://one.url/status
    labels:
      environment: production
      role: load_balancer
 - name: nginx2.myorg.com-metrics
   command: metrics
   arguments:
     status_url: http://another.url/status
   labels:
     environment: production
     role: load_balancer

Définitions des champs du fichier de configuration

Champ du fichier de configuration	Description
`integration_name`	Requis. Il s'agit de l'en-tête et il est utilisé pour identifier les exécutables à exécuter. Ce nom doit correspondre exactement au nom spécifié dans le fichier de définition de l'intégration. Recommandation : pour garantir des noms uniques, utilisez la notation de nom de domaine inversée.
`name`	Requis. Il s’agit du nom de l’invocation spécifique (instance) de l’intégration. Ceci est utilisé pour aider à identifier tout message de log généré par cette intégration et est également utile pour le dépannage.
`command`	Requis. C'est la commande à exécuter. Cela doit correspondre exactement à l’un des noms d’alias uniques spécifiés dans le fichier de définition de l’intégration.
`arguments`	Facultatif. Un objet YAML où : Clés : le nom de l'argument. Transformé en majuscules lorsqu'il est défini comme variable d'environnement. Valeurs : les valeurs de l’argument. Transmis tel quel. Les arguments sont mis à disposition d'une intégration sous la forme d'un ensemble de variables d'environnement. Les arguments dans le fichier de configuration ne peuvent pas être en majuscules et doivent utiliser des traits de soulignement pour séparer les mots.
`labels`	Facultatif. Un objet YAML où : Clés : Le nom de l'étiquette. Valeurs : la valeur de l’étiquette définie.
`integration_user`	Facultatif. Chaîne avec le nom que l'agent utilisera pour exécuter le binaire d'intégration. Par défaut : dépend du `usermode`. Par défaut, l'intégration est exécutée avec le même utilisateur qui exécute l'agent d'intégration, nri-agent pour le mode privilégié et non privilégié et l'utilisateur root pour le mode root. Lorsqu'il est présent, l'agent d'infrastructure exécutera le binaire d'intégration en tant qu'utilisateur spécifié. Par exemple, pour exécuter le binaire d'intégration en tant qu'utilisateur root lors de l'exécution de l'agent dans un `usermode` différent de `root`, ajoutez simplement `integration_user: root` au fichier de configuration.

Cette traduction automatique est fournie pour votre commodité.