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.

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.

Configuring Fluent Bit on hosts

On hosts, Fluent Bit isn't deployed as its own top-level agent type (see the support table above). Instead, when log forwarding is enabled, Fluent Bit is spawned and managed by the New Relic infrastructure agent itself, the same way as when it's installed standalone. Agent Control only changes where the infrastructure agent, its data, and the Fluent Bit binary and plugin live on disk.

For how to configure log forwarding itself (logging.d/*.yml syntax, inputs, filters, attributes, and so on), see:

• Enable log management
• Forward logs with Fluent Bit

Where to put your configuration

The only Agent-Control-specific detail is where log forwarding files go: they land in the sub-agent's logging.d folder, one entry per log source, via the config_logging field of the infrastructure agent's config. Set it directly in the sub-agent's config (for example, its local_config.yaml) and send that to 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

Where Fluent Bit lives, and how it's updated