intégration sur hôte : Format configuration standard

En décembre 2019, la version 1.8.0 de l'agent d'infrastructure a commencé à prendre en charge ce nouveau format de configuration qui utilise un seul fichier de configuration (au lieu de deux fichiers distincts) et apporte d'autres améliorations. Ce document explique comment fonctionne ce nouveau format.

L'ancien format de configuration hérité est également pris en charge par les agents d'infrastructure actuels.

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

Structure de configuration

La configuration YAML d'une intégration sur hôte doit avoir une section de niveau supérieur integrations contenant un éventail YAML, où chaque entrée représente une intégration et sa configuration.

Pour chaque entrée d'intégration, seule la propriété name est obligatoire. Les autres propriétés sont facultatives.

Voici un exemple configuration comportant deux intégrations : notre intégrationDocker intégrée, qui ne nécessite aucune configuration, et notre intégrationMySQL :

integrations:
  # New Relic integration that does not require any configuration
  - name: nri-docker
  # New Relic integration that gets its configuration from the environment
  - name: nri-mysql
    env:
      PORT: 3306
      USERNAME: newrelic
      PASSWORD: 123456789 # to hide this field, read the secrets management documentation
  # Any free-form integration executed via a user-provided command
  - name: my-own-integration
    exec: python /opt/integrations/my-script.py --host=127.0.0.1

Vous pouvez avoir autant de fichiers configuration YAML que vous le souhaitez et regrouper votre instance d'intégration.

Conseil

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

Chaque fichier de configuration YAML peut également contenir des sections de niveau supérieur discovery et variables .

Important

Ce format de configuration ne nécessite pas de redémarrage de l'agent. Une fois enregistrées, les modifications sont détectées et implémentées immédiatement. Cela signifie que l’enregistrement des modifications de configuration intermédiaires peut entraîner l’arrêt du fonctionnement de l’intégration.

Liste des propriétés de configuration

Il s'agit d'une liste des propriétés générales utilisées pour configurer une intégration. Pour plus de détails sur l'utilisation de ces propriétés, y compris des exemples de valeurs, consultez la documentation suivant le tableau.

Configuration	Description
`name`	Nom de l'intégration. Il s'agit de la seule propriété configuration obligatoire sur toute l'intégration sur hôte. Si le champ `exec` n'est pas défini, ce sera également le nom de l'exécutable d'intégration.
`cli_args`	Liste facultative d'arguments de ligne de commande lorsque `name` est utilisé pour fournir l'exécutable d'intégration. Disponible depuis la version d'agent 1.13.0.
`exec`	Chemin complet vers l'exécutable d'intégration, plus les arguments. Il peut s'agir d'une chaîne à une seule ligne ou d'un éventail de chaînes. Si ce champ n'est pas spécifié, la valeur par défaut du champ `exec` est le champ `name` .
`env`	Carte YAML contenant les variables d'environnement à transmettre à l'intégration, où `key` est le nom de la variable d'environnement et `value` est la valeur de la variable.
`config`	configuration qui est écrite sous forme de fichier externe et le chemin qui est passé à l'intégration avec la variable d'environnement `CONFIG_PATH` ou la variable `${config.path}` espace réservé.
`config_template_path`	Tout fichier externe dont le chemin est transmis à l’intégration avec la variable d’environnement `CONFIG_PATH` ou l’espace réservé à la variable `${config.path}` . Son utilisation permet d'appliquer la découverte et la liaison de secrets à n'importe quelle configuration externe.
`integration_user`	Nom de l'utilisateur qui exécute l'intégration.
`interval`	Temps entre les exécutions consécutives de l'intégration. Il doit s'agir d'un nombre suivi d'une unité de temps (`s`, `m` ou `h`), sans espaces.
`inventory_source`	Permet de remplacer la catégorie et le terme de la source d'inventaire.
`labels`	Carte avec des étiquettes qui agrémentent les données (métriques, événement, inventaire) remontées par l'intégration.
`timeout`	Un nombre suivi d'une unité de temps (`ms`, `s`, `m` ou `h`). Une intégration qui n’a pas répondu pendant cette période est arrêtée et redémarrée.
`working_dir`	Répertoire de travail pour le binaire d'intégration.
quand	L'intégration n'est exécutée que si la clause est évaluée à vrai. Les conditions sont définies ci-dessous.

Le reste de ce document décrit les propriétés de configuration regroupées par fonctionnalité :

Sélectionnez une intégration à exécuter
Transmettre la configuration à la commande d'intégration
Configurer la manière dont l’agent exécute l’intégration

Sélectionnez une intégration à exécuter

Il existe deux propriétés permettant de sélectionner l'intégration à exécuter : name et exec.

La seule propriété obligatoire dans toute l'intégration sur hôte est name. Les propriétés restantes spécifiées dans ce document sont facultatives.

Exemple:

integrations:
  - name: nri-docker
  - name: my-integration
    exec: /usr/local/bin/my-integration --metrics --inventory

La propriété obligatoire name peut fonctionner de deux manières :

If the exec property is set: La propriété name fournit uniquement un identifiant pour l'instance d'intégration. Cet identifiant est utilisé dans le message de log et pour fournir une catégorie/source d'inventaire par défaut sous la forme integration/<name> (par exemple, integration/nri-redis). Ce chemin d'inventaire peut être remplacé par l'option de configuration inventory_source .
If the exec property is not set:L'agent recherche (et exécute) un exécutable avec la valeur name dans l'un des dossiers suivants :
- Linux:
  - /var/db/newrelic-infra/newrelic-integrations/bin
  - /var/db/newrelic-infra/newrelic-integrations
  - /var/db/newrelic-infra/custom-integrations/bin
  - /var/db/newrelic-infra/custom-integrations
- Windows
  - C:\Program Files\New Relic\newrelic-infra\newrelic-integrations\bin
  - C:\Program Files\New Relic\newrelic-infra\newrelic-integrations
S'il n'y a pas d'exécutable portant ce nom dans les dossiers ci-dessus, l'agent enregistre une erreur et l'intégration n'est pas exécutée.
Important
Sous Windows, n’ajoutez pas l’extension .exe au nom. L'agent le fait pour vous (par exemple, name: nri-mysql rechercherait nri-mysql.exe dans les dossiers ci-dessus).

La propriété facultative exec spécifie le chemin, la commande et les arguments de ligne de commande de l'intégration à exécuter. Lorsqu'aucun des dossiers de chemin ou des arguments ne contient d'espaces, il peut être écrit dans une chaîne sur une seule ligne :

- name: my-integration
  exec: /usr/bin/python /opt/integrations/my-script.py --host=127.0.0.1

Si l'un des chemins ou des arguments contient des espaces faisant partie d'un seul élément, vous pouvez utiliser une notation éventail YAML. Pour Windows, assurez-vous d'échapper aux barres obliques inverses avec des guillemets comme ceci :

- name: my-integration
  exec:
    - '"C:\Program Files\My Integration\integration.exe"'
    - --host
    - 127.0.0.1
    - --port
    - 8080

Le répertoire de travail par défaut est le répertoire racine de la configuration de l'agent. Il peut être remplacé par la propriété working_dir .

La propriété facultative cli_args spécifie les arguments de ligne de commande qui doivent être transmis à l'intégration. Il est utile lors de l'utilisation name car il fournit uniquement l'identifiant du nom d'intégration (non compatible avec exec).

- name: my-integration
  cli_args: [ -interval 10s ]

Le format de liste multiligne YAML habituel peut également être utilisé :

- name: my-integration
  cli_args:
    - -interval
    - 10s

La propriété when permet d'exécuter l'intégration uniquement lorsque toutes les conditions évaluées sont réussies.

Les conditions disponibles sont :

env_exists:Les variables d'environnement existent et correspondent à la valeur.
file_exists:Le chemin de fichier donné existe.

feature: À condition que l'indicateur de fonctionnalité soit activé.

Exemple:

integrations:
  - name: ssh-integration
    when:
      file_exists: /var/run/sshd.pid

Transmettre la configuration à l'exécutable d'intégration

Souvent, les exécutables d'intégration ont besoin de recevoir une configuration pour fonctionner correctement (par exemple, nom d'hôte et port du système de monitoring, identifiants de l'utilisateur, etc.).

L'agent d'infrastructure vous permet de configurer les commandes d'intégration de trois manières (que vous pouvez combiner) :

Variables d'environnement, utilisant la propriétéenv . (recommandé)
Arguments de ligne de commande, passés dans la propriétéexec .
Fichiers de configuration, dont le chemin doit être transmis via des variables d'environnement ou des arguments de ligne de commande (voir la propriété config).

Exemple:

integrations:
  - name: my-integration
    exec: /opt/path/bin/script --host 127.0.0.1 --port 8081
  - name: nri-mysql
    env:
      STATUS_URL: http://10.0.0.3/server-status?auto
      REMOTE_MONITORING: true

La propriété env vous permet de définir des variables d’environnement qui sont transmises à l’exécutable. Il s'agit d'une carte valeur clé avec les variables requises.

Important

New Relic recommande de transmettre les clés env en majuscules, comme dans l'exemple ci-dessous, pour la compatibilité avec toutes les versions d'agent d'infrastructure depuis la version 1.8.0.
Si vous utilisez la version 1.20.0 ou supérieure de l'agent, vous pouvez utiliser des lettres minuscules car l'agent les mettra automatiquement en majuscules.

Exemple:

integrations:
  - name: nri-postgresql
    env:
      DATABASE: postgres
      PORT: 6432
      COLLECTION_LIST: '["postgres"]'
      COLLECT_DB_LOCK_METRICS: false
      VERBOSE: 1

Si vous vous attendez à ce que votre intégration reçoive la configuration de l'environnement de l'hôte plutôt que de la spécifier explicitement dans le fichier de configuration, vous devez définir les variables requises dans la propriété de configuration globale passthrough_environment de l'agent d'infrastructure

Cette section décrit différentes manières de transmettre des informations de configuration à une intégration.

Pass configuration file directly

Certaines commandes d'intégration peuvent obtenir leur configuration à partir d'un fichier externe. Si votre intégration nécessite un fichier de configuration, rien ne vous empêche de passer directement son chemin directement en argument de ligne de commande ou en variable d'environnement. Voici un exemple utilisant la configuration de notre intégration Flex:

integrations:
  - name: nri-flex
    env:
      CONFIG_FILE: /etc/nri-flex/configs/http-service.yaml
  - name: other-integration
    exec: /opt/integration/integration -f /opt/integration/config.properties

L'exemple ci-dessus suppose que les fichiers http-service.yaml et config.properties existent. Nous pouvons voir que l'intégration nri-flex attend le chemin complet http-service.yaml via la variable d'environnement CONFIG_FILE et que other-integration attend le chemin complet config.properties après l'indicateur de ligne de commande -f .

Dans l'exemple ci-dessus, il est nécessaire pour le programme d'intégration d'installation/configurateur que les fichiers configuration existent dans le chemin fourni et que l'agent et l'intégration aient des autorisations de lecture sur eux.

Pass configuration through config section

Si vous préférez conserver votre fichier de configuration avec le reste de la configuration d'intégration, vous pouvez utiliser la section config dans l'entrée d'intégration, qui peut contenir un objet YAML valide ou simplement une chaîne multiligne :

integrations:
  - name: nri-flex
    env:
      CONFIG_FILE: ${config.path}
    config:
      name: csvFileExample
      apis:
        - name: csvFile
          file: /Users/hello/test.csv
  - name: other-integration
    exec: /opt/integration/integration -f ${config.path}
    config: |
      example.cfg.verbose=true
      example.cfg.logger=/var/logs/integration.log
      example.cfg.hostname=localhost
      example.cfg.port=9025

Dans les exemples ci-dessus, chaque fois que l'intégration nri-flex est exécutée, l'agent crée un fichier temporaire avec le contenu suivant :

name: csvFileExample
apis:
  - name: csvFile
    file: /Users/hello/test.csv

Le YAML ci-dessus n'est qu'un exemple de configuration pour l'intégration nri-flex . L'agent ignore son contenu ; à la place, il crée un fichier temporaire et remplace l'espace réservé à la variable ${config.path} par son chemin. Une fois l'intégration terminée, le fichier temporaire est supprimé.

De plus, l'agent crée un autre fichier temporaire avant d'exécuter l'intégration other-integration :

example.cfg.verbose=true
example.cfg.logger=/var/logs/integration.log
example.cfg.hostid=localhost
example.cfg.port=9025

Il remplace l'espace réservé de la ligne de commande -f ${config.path} par le chemin temporaire du fichier écrit.

Par convention, si vous ne placez pas la variable ${config.path} dans un argument de ligne de commande ou une valeur de variable d'environnement, l'agent transmet le chemin du fichier de configuration via la variable d'environnement CONFIG_PATH :

# assuming that nri-example command is prepared to receive the configuration
# file via the CONFIG_PATH environment variable
integrations:
  - name: nri-example
    config:
      name: csvFileExample
      apis:
        - name: csvFile
          file: /Users/hello/test.csv

Pass secrets and discovery through config section

Le principal avantage de l'utilisation d'une section config au lieu de coder en dur le chemin complet d'un fichier externe est que vous pouvez insérer un espace ${variable} réservé pour appliquer notre fonctionnalité de découverte automatique et de gestion des secrets.

Voici un exemple suivi de quelques explications :

variables:
  my_credentials:
    vault:
      http:
        url: http://my.vault.host/v1/newengine/data/secret
        headers:
          X-Vault-Token: my-vault-token
discovery:
  docker:
    match:
      label.service: foo
integrations:
  - name: foo-monitor
    exec: /opt/foo/bin/monitor --config=${config.path}
    config: |
      foo.host=${discovery.ip}
      foo.port=${discovery.port}
      foo.user=${my_credentials.user}
      foo.password=${my_credentials.password}

Conseil

(Pour plus de détails sur les sections variables et discovery , veuillez consulter la documentation sur la découverte et la gestion des secrets ).

L'exemple ci-dessus repose sur les prémisses suivantes :

Il existe un service Vault qui permet de récupérer un objet JSON formé des champs user et password .
Il peut y avoir un nombre variable de conteneurs Docker étiquetés avec service=foo, qui sont accessibles depuis l'agent hôte via une IP publique et un port détectables.
L'utilisateur a configuré l'intégration foo-monitor pour monitorer tous les conteneurs étiquetés service=foo , qui partagent un utilisateur et un mot de passe communs. Chaque instance de l'intégration foo-monitor nécessite l'exécution de l'exécutable /opt/foo/bin/monitor , en passant la configuration du texte à l'intérieur de la section config via l'argument de ligne de commande --config=<path> .

À titre d’exemple de workflow, imaginez que l’invocation de Vault renvoie le JSON suivant :

{"user":"monitorer","password":"5up3r53cr3t!"}

Au moment de l'exécution de l'intégration foo-monitor , il y a trois conteneurs en cours d'exécution étiquetés avec service=foo:

adresse IP : 10.0.0.3, port : 8080
adresse IP : 10.0.0.3, port : 8081
adresse IP : 10.0.0.3, port : 8082

L'agent crée ensuite les trois fichiers temporaires suivants, en utilisant le contenu de la propriété config comme modèle, mais en remplaçant le ${placeholders} par les variables acquises et les éléments découverts (le chemin des fichiers est inventé par souci de simplicité) :

Premier match (/tmp/123_discovered):

foo.host=10.0.0.3
foo.port=8080
foo.user=monitorer
foo.password=5up3r53cr3t!

Deuxième match (/tmp/456_discovered):

foo.host=10.0.0.3
foo.port=8081
foo.user=monitorer
foo.password=5up3r53cr3t!

Troisième match (/tmp/789_discovered)

foo.host=10.0.0.3
foo.port=8082
foo.user=monitorer
foo.password=5up3r53cr3t!

Après que la variable config espace réservé a été remplacée et que les fichiers temporaires ont été créés, l'exécutable /opt/foo/bin/monitor est exécuté trois fois (une par conteneur correspondant), en remplaçant la ligne de commande ${config.path} espace réservé par le fichier temporaire correspondant à chaque configuration découverte :

Premier match : /opt/foo/bin/monitor --config=/tmp/123_discovered
Deuxième match : /opt/foo/bin/monitor --config=/tmp/456_discovered
Troisième match : /opt/foo/bin/monitor --config=/tmp/789_discovered

Pour garantir la sécurité et minimiser les risques de fuite de secrets sur le disque, l'agent :

Crée les fichiers appartenant à l'utilisateur de l'agent, par exemple, root ou nri-agent, selon l'utilisateur que vous avez configuré pour exécuter l'agent.
Définit les autorisations de lecture uniquement pour le propriétaire.
Supprime les fichiers créés lorsque l'instance d'intégration termine son exécution.

Si vous souhaitez utiliser la gestion et la découverte des secrets dans les fichiers de configuration que vous transmettez à l'exécutable d'intégration, mais que vous préférez les conserver sous forme de fichier individuel, vous pouvez utiliser l'option config_template_path: <path> . Cela fonctionne exactement comme dans la section config :

L'agent applique la gestion des secrets et la découverte au contenu du fichier.
L'agent crée différents fichiers temporaires qui sont transmis à l'intégration via l'espace réservé ${config.path} (ou la variable d'environnement CONFIG_PATH ).
Exemple:
```
discovery:
    docker:
      match:
        name: /^redis/
  integrations:
    - name: nri-flex
      env:
        CONFIG_FILE: ${config.path}
      config_template_path: /etc/flex-configs/redis.yml
```
Dans l'exemple ci-dessus, le fichier externe redis.yml peut contenir un espace de variable de découverte de conteneur réservé, comme ${discovery.ip} ou ${discovery.port}.

Configurer la manière dont l'agent exécute votre intégration

Les propriétés de cette section modifient la manière dont l'agent infrastructure s'exécute et interagit avec l'intégration, ou la manière dont l'agent décore les données de l'intégration.

Les commandes d'intégration s'exécutent avec le même utilisateur que l'agent (généralement root ou nri-agent). Si, en raison de restrictions d'autorisation, une intégration doit s'exécuter sous le nom d'un autre utilisateur, son nom doit être spécifié dans la propriété integration_user .

Exemple:

integrations:
  - name: dbus-inventory
    exec: python my-dbus-script.py
    integration_user: dbus

L'option interval définit le temps entre les exécutions consécutives d'une intégration. Le format accepté est un entier immédiatement suivi d'une unité de temps (s pour les secondes, m pour les minutes, h pour les heures).

La valeur par défaut est 30s et la valeur minimale acceptée est 15s. Toute valeur inférieure à 15s est automatiquement définie sur 15s.

Exemple:

integrations:
  - name: nri-nginx
    env:
      STATUS_URL: http://127.0.0.1/status
      STATUS_MODULE: discover
    interval: 20s

Tout élément d’inventaire doit être catalogué sous une taxonomie category/source . Par défaut, chaque inventaire d'intégration est stocké sous la forme d'une valeur integration/ + name (par exemple, integration/nri-apache, integration/nri-mysql).

La propriété inventory_source vous permet de remplacer la taxonomie par défaut des données d'inventaire.

Exemple:

integrations:
  - name: nri-nginx
  - name: nri-apache
    exec:
      - /var/db/newrelic-infra/newrelic-integrations/bin/nri-apache
      - --inventory
    inventory_source: config/apache

Dans l'exemple ci-dessus, l'inventaire nri-nginx, le cas échéant, serait visible dans l'UI de New Relic sous la source integration/nri-nginx. L'inventaire nri-apache serait visible sous config/apache.

labels est une carte valeur clé qui permet de fournir des métadonnées supplémentaires pour l'intégration. L'agent utilise ces étiquettes pour décorer les métriques, les événements et l'inventaire qu'il reçoit d'une instance d'intégration donnée.

Exemple:

integrations:
  - name: nri-apache
    inventory_source: config/apache
    labels:
      env: production
      role: load_balancer

Dans l'exemple ci-dessus, l'agent décore toutes les métriques et événements de l'instance nri-apache avec les champs suivants :

label.env: production
label.role: load_balancer

De plus, les entrées suivantes sont ajoutées à l’inventaire d’intégration :

config/apache/labels/env: production
config/apache/labels/role: load_balancer

Si une intégration n'a renvoyé aucune métrique (ou un message de pulsation comme décrit ci-dessous) avant l'heure spécifiée dans la valeur timeout , l'agent arrête le processus d'intégration et le redémarre après le interval correspondant. Le format accepté est un nombre entier immédiatement suivi (sans espaces) d'une unité de temps (ms pour les millisecondes, s pour les secondes, m pour les minutes, h pour les heures).

Si une valeur timeout nulle (ou négative) est fournie, l'intégration peut s'exécuter indéfiniment sans être interrompue par une expiration de délai.

Pour les intégrations de longue durée (intégrations qui continuent de fonctionner, renvoyant périodiquement des métriques/événement/inventaire), chaque fois que l'intégration soumet une charge métriques/événement/inventaire, le délai d'expiration est redémarré. Cela signifie que l'intégration de longue durée doit renvoyer une charge JSON valide dans un intervalle inférieur à timeout.

Le renvoi d'un JSON vide ({}) est interprété comme un message de pulsation qui redémarre le délai d'expiration, empêchant l'arrêt de l'intégration de longue durée, même si elle n'a pas d'informations à signaler.

La valeur par défaut est 120s et la valeur minimale acceptée est 100ms. Toute valeur inférieure à 100ms est automatiquement définie sur 100ms.

Exemple:

integrations:
  - name: nri-jmx
    cli_args:
      JMX_HOST: jmx-host.localnet
      JMX_PORT: 7096
      COLLECTION_FILES: "/etc/newrelic-infra/integrations.d/jvm-metrics.yml"
    timeout: 30s

working_dir définit le répertoire de travail de la commande. Si vide ou non spécifié, l'agent exécute la commande dans le répertoire actuel de l'agent d'infrastructure.

La valeur par défaut est le répertoire racine de l’agent d’infrastructure.

Exemple:

integrations:
  - name: my-integration
    exec: /opt/integration/bin/integration
    working_dir: /opt/integration/scratch-zone

Mettre à jour l’ancienne configuration d’intégration

En décembre 2019, la version 1.8.0 de l'agent d'infrastructure a commencé à utiliser un format de configuration différent.

La principale différence entre ces formats est que l'ancien format de configuration utilise deux fichiers de configuration distincts (un fichier INTEGRATION_NAME-definition.yml et un fichier INTEGRATION_NAME-config.yml ) et la version plus récente utilise un seul fichier de configuration.

Voici quelques-unes des fonctionnalités ajoutées par la nouvelle fonctionnalité de configuration :

configuration flexible via des arguments de ligne de commande, des variables d'environnement ou des fichiers externes.
Possibilité de regrouper différentes intégrations dans un même fichier.
Rechargement à chaud : l'ajout d'une nouvelle intégration ou la modification de sa configuration ne nécessite pas de redémarrage de l'agent.
Délais d'expiration : si une intégration ne répond pas avant un délai spécifié par l'utilisateur, le processus d'intégration est arrêté et redémarré.

Toutes les intégrations sur hôte ne sont pas livrées avec le nouveau format configuration , mais vous pouvez mettre à jour la configuration vers le nouveau format pour toutes les intégrations sur hôte afin de profiter de la nouvelle fonctionnalité.

Le YAML suivant montre un exemple de configuration d’intégration Apache utilisant l’ancien format de configuration. Notez que cette configuration fonctionnera toujours avec les agents plus récents, mais nous vous recommandons de mettre à jour votre intégration pour profiter pleinement des fonctionnalités.

integration_name: com.newrelic.apache

instances:
  - name: apache-server-metrics
    command: metrics
    arguments:
      status_url: http://127.0.0.1/server-status?auto
      remote_monitoring: true
    labels:
      env: production
      role: load_balancer
  - name: apache-server-inventory
    command: inventory
    arguments:
      remote_monitoring: true
    labels:
      env: production
      role: load_balancer

Pour mettre à jour une ancienne configuration d’intégration vers le nouveau format, utilisez l’une des méthodes suivantes :

Méthode assistée

À l’aide de la CLI New Relic, exécutez la commande suivante pour convertir automatiquement vos anciens fichiers de définition/configuration au nouveau format de configuration :

bash

$newrelic agent config migrateV3toV4 -d /path/definitionFile -c /path/configFile -o /path/outputFile

Exemples :

Le chemin utilisé ci-dessous est l'emplacement par défaut pour l'intégration basée sur Linux. Vous devrez peut-être ajuster le chemin si vous utilisez un emplacement personnalisé :

newrelic agent config migrateV3toV4 \
 -d /var/db/newrelic-infra/newrelic-integrations/redis-definition.yml \
 -c /etc/newrelic-infra/integrations.d/redis-config.yml \
 -o /etc/newrelic-infra/integrations.d/redis.yml

Le chemin utilisé ci-dessous est l'emplacement par défaut pour l'intégration basée sur Windows . Vous devrez peut-être ajuster le chemin si vous utilisez un emplacement personnalisé :

newrelic agent config migrateV3toV4 ^
 -d 'C:\Program Files\New Relic\newrelic-infra\newrelic-integrations\mssql-definition.yml' ^
 -c 'C:\Program Files\New Relic\newrelic-infra\integrations.d\mssql-config.yml' ^
 -o 'C:\Program Files\New Relic\newrelic-infra\integrations.d\mssql.yml'

Méthode manuelle

Pour convertir le fichier d’intégration manuellement :

Renommez la section de niveau supérieur instances en integrations.
Supprimez la section de niveau supérieur integration_name et ajoutez-la à chaque entrée d'intégration. Vous n’êtes plus obligé de conserver un fichier distinct pour chaque type d’intégration et vous pouvez regrouper vos entrées d’intégration legacy dans le même fichier que les autres intégrations.

Voici un exemple de la nouvelle version de la configuration de l'intégration Apache :

integrations:
  - name: nri-apache
    env:
      METRICS: "true"
      STATUS_URL: http://127.0.0.1/server-status?auto
      REMOTE_MONITORING: true
    interval: 15s
    labels:
      env: production
      role: load_balancer

  - name: nri-apache
    env:
      INVENTORY: "true"
      STATUS_URL: http://127.0.0.1/server-status?auto
      REMOTE_MONITORING: true
    interval: 60s
    labels:
      env: production
      role: load_balancer
    inventory_source: config/apache

Important

Veuillez noter que l'ancien format de configuration ne prend pas en charge le rechargement à chaud. Par conséquent, vous devez redémarrer l’agent infrastructure pour supprimer l’ancienne configuration d’intégration. Sinon, l’ancienne instance coexistera avec les nouvelles.

Cette traduction automatique est fournie pour votre commodité.

intégration sur hôte : Format configuration standard

Structure de configuration

Conseil

Important

Liste des propriétés de configuration

Sélectionnez une intégration à exécuter

`name`

Important

`exécutif`

`cli_args`

`quand`

Transmettre la configuration à l'exécutable d'intégration

`env`

Important

`configuration`

Conseil

`config_template_path`

Configurer la manière dont l'agent exécute votre intégration

`integration_user`

`intervalle`

`inventory_source`

`labels`

`temps mort`

`working_dir`

Mettre à jour l’ancienne configuration d’intégration

Méthode assistée

Redis

Microsoft SQL

Méthode manuelle

Important

Cette traduction automatique est fournie pour votre commodité.

intégration sur hôte : Format configuration standard

Structure de configuration .css-21sua1{background:none;border:none;width:0;padding:0;}

Conseil

Important

Liste des propriétés de configuration

Sélectionnez une intégration à exécuter

exécutif

cli_args

quand

Transmettre la configuration à l'exécutable d'intégration

env

configuration

config_template_path

Configurer la manière dont l'agent exécute votre intégration

integration_user

intervalle

inventory_source

labels

temps mort

working_dir

Mettre à jour l’ancienne configuration d’intégration

Méthode assistée

Redis

Microsoft SQL

Méthode manuelle

Important

Structure de configuration

`exécutif`

`cli_args`

`quand`

`env`

`configuration`

`config_template_path`

`integration_user`

`intervalle`

`inventory_source`

`labels`

`temps mort`

`working_dir`