Types d’agents

Une définition de type d’agent est un fichier YAML qui décrit comment Agent Control doit identifier, télécharger, configurer et exécuter un agent spécifique. Ses variables déclarées forment également le schéma de configuration que le contrôle de la flotte expose aux opérateurs lors du déploiement ou de la mise à jour d’un sous-agent de la flotte. Chaque définition se compose de trois sections principales, metadata, variables, et deployment, plus un champ protocol_version de niveau supérieur qui définit la version du langage de schéma dans lequel le fichier est écrit.

Métadonnées

La section des métadonnées identifie le type d’agent : ses name, namespace, version, sa cible platform (host ou kubernetes), et operating_system (requis pour les types basés sur l’hôte). Agent Control utilise ces champs pour adresser de manière unique la définition et l’envoyer au moteur de déploiement correct.

Variables

La section des variables déclare les entrées configurables que les opérateurs peuvent définir lors de l'ajout d'un sous-agent à leur configuration. Chaque variable a un type (tel que string, bool, ou yaml), un default facultatif, et une liste variants facultative de valeurs acceptées. Les variables sont référencées tout au long de la section de déploiement à l'aide de ${nr-var:variable_name}.

déploierons

La section de déploiement décrit comment Agent Control installe et exécute l’agent sur la plateforme cible. Elle est composée de plusieurs sous-sections :

• packages: artefacts OCI à télécharger avant le démarrage de l’agent — généralement le binaire de l’agent ou le package d’intégration.
• executables: la liste des processus qu’Agent Control va démarrer, monitorer, et redémarrer. Un type d’agent sans cette section est traité comme une intégration gérée (OHI) : Agent Control gère ses artefacts, mais délègue l’exécution à un autre agent.
• health: comment Agent Control détermine si l’agent est sain, via la présence du processus, une vérification du point de terminaison HTTP, ou les deux.
• filesystem: fichiers ou répertoires individuels qu’Agent Control écrit sur l’hôte avant de démarrer l’agent, tels que des fichiers de configuration ou des certificats.
• shared_filesystem: les entrées écrites dans une zone de dépôt partagée accessible aux autres agents gérés par la même instance d’Agent Control. Utilisé par les types d’agent OHI pour transmettre leur configuration et leurs binaires à l’agent d’infrastructure.

Pour la référence complète du schéma et tous les champs disponibles, consultez la référence du schéma de type d’agent.

Récupérer les définitions de type d'agent

Agent Control récupère les définitions de type d’agent à partir d’un registre OCI distant, identifiées par les namespace, name, et version déclarés dans la section des métadonnées de la définition.

Par défaut, Agent Control récupère depuis docker.io, en utilisant le référentiel newrelic/agent-control-agent-types.

Agent Control vérifie la signature de chaque définition avec la clé publique New Relic avant de la télécharger.

Vous pouvez mettre en miroir ce registre de la même manière que les packages d’agent.

Types d’agents liés

Deux types d’agents sont liés lorsque l’un écrit des artefacts (configuration, binaires ou autres fichiers) dans le système de fichiers partagé et que l’autre est configuré pour lire à partir de ces mêmes chemins. L’agent d’écriture peut n’avoir aucune section executables, Agent Control gère ses artefacts mais ne démarre jamais de processus pour lui. Au lieu de cela, l’agent lecteur possède la logique intégrée pour découvrir et exécuter les binaires et la configuration à partir d’un chemin bien connu dans le système de fichiers partagé, exécutant ainsi l’extension pour le compte de l’agent d’écriture.

La racine du système de fichiers partagé est :

Tous les agents gérés par la même instance Agent Control partagent cette racine. Les noms de sous-répertoires sont choisis par convention entre les types d’agents liés.

Intégrations sur hôte (OHI)

Les intégrations sur hôte (OHI) sont le principal exemple d’agents liés dans Agent Control ; là où d’autres agents ont un processus démarré par Agent Control, les agents OHI n’ont pas de processus propre, et Agent Control ne les démarre jamais. Elles permettent à Agent Control de gérer le cycle de vie complet des intégrations de New Relic Infrastructure, en les téléchargeant, en les configurant, en les mettant à niveau et en les désinstallant tout en déléguant leur exécution à l’agent d’infrastructure, qui découvre et exécute les binaires d’intégration à partir du système de fichiers partagé.

La relation entre l’agent d’infrastructure et l’agent OHI

1. Lorsqu'un type d'agent OHI est installé, Agent Control télécharge le binaire d'intégration via OCI, et écrit deux entrées dans le système de fichiers partagé :

   • Un fichier de configuration sous infra-agent-ohi-configs/ (par ex. nri-redis.yaml)
   • Le binaire d’intégration sous infra-agent-ohi-binaries/ (par ex. nri-redis)

2. Le sous-agent de l’agent d’infrastructure est configuré avec des variables d’environnement qui le pointent vers ces répertoires partagés :

   Variable	Chemin du système de fichiers partagé	But
   NRIA_PLUGIN_DIR	…/infra-agent-ohi-configs	Découverte de la configuration de l’intégration
   NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR	…/infra-agent-ohi-binaries	Découverte du binaire de l’intégration
   NRIA_SAFE_BIN_DIR	…/infra-agent-ohi-binaries	Chemin d'exécution de binaire autorisé

3. L’agent d’infrastructure récupère la configuration et le binaire lors de son prochain cycle d’analyse et commence à exécuter l’intégration.

   shared-filesystem/
   ├── infra-agent-ohi-configs/      # Integration YAML configs (read by NRIA_PLUGIN_DIR)
   │   ├── nri-redis.yaml
   │   └── nri-mysql.yaml
   └── infra-agent-ohi-binaries/     # Integration binaries (read by NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR)
       ├── nri-redis
       └── nri-mysql

   Copier

Types d'agents pris en charge

Support actuel

Le tableau suivant indique les types d’agents pris en charge par Agent Control et leur disponibilité dans les différents environnements.

Autorisations requises par type d’agent

Le tableau suivant répertorie les autorisations clés requises par chaque type d’agent et les environnements dans lesquels il s’applique.

Configuration de Fluent Bit sur les hôtes

Sur les hôtes, Fluent Bit n’est pas déployé en tant que type d’agent de niveau supérieur à part entière (voir le tableau de prise en charge ci-dessus). Au lieu de cela, lorsque le transfert de logs est activé, Fluent Bit est généré et géré par l’ agent d’infrastructure New Relic lui-même, de la même manière que lorsqu’il est installé de façon autonome. Agent Control modifie uniquement l’ emplacement où l’agent d’infrastructure, ses données, ainsi que le binaire et le plug-in Fluent Bit résident sur le disque.

Pour savoir comment configurer le transfert de logs lui-même (syntaxe logging.d/*.yml, entrées, filtres, attributs, etc.), consultez :

• Activer la gestion des logs
• Transférer les logs avec Fluent Bit

Où placer votre configuration

Le seul détail spécifique à Agent Control est l’emplacement où vont les fichiers de transfert de logs : ils atterrissent dans le dossier logging.d du sous-agent, une entrée par source de log, via le champ config_logging de la configuration de l’agent d’infrastructure. Définissez-le directement dans la configuration du sous-agent (par exemple, son local_config.yaml) et envoyez-le à Agent Control :

config_logging:
  syslog.yaml: |
    logs:
      - name: syslog
        file: /var/log/syslog
        attributes:
          logtype: linux_syslog
  app.yaml: |
    logs:
      - name: app-log
        file: /var/log/app.log
        attributes:
          service: api
          env: production

Où réside Fluent Bit et comment il est mis à jour