Tipos de agentes

Una definición de tipo de agente es un archivo YAML que describe cómo Agent Control debe identificar, descargar, configurar y ejecutar un agente específico. Sus variables declaradas también forman el esquema de configuración que el control de flota expone a los operadores al desplegar o actualizar un subagente de la flota. Cada definición consta de tres secciones principales, metadata, variables y deployment, además de un campo protocol_version de nivel superior que versiona el lenguaje de esquema en el que está escrito el archivo.

Metadatos

La sección de metadatos identifica el tipo de agente: su name, namespace, version, platform objetivo (host o kubernetes) y operating_system (necesario para los tipos basados en host). Agent Control utiliza estos campos para direccionar de forma exclusiva la definición y enviarla al motor de despliegue correcto.

Variables

La sección de variables declara las entradas configurables que los operadores pueden establecer al agregar un subagente a su configuración. Cada variable tiene un type (como string, bool o yaml), un default opcional y una lista variants opcional de valores aceptados. Las variables se referencian en toda la sección de despliegue mediante ${nr-var:variable_name}.

Despliegue

La sección de despliegue describe cómo Agent Control instala y ejecuta el agente en la plataforma objetivo. Se compone de varias subsecciones:

• packages: artefactos de OCI para descargar antes de que se inicie el agente —por lo general, el binario del agente o el paquete de integración.
• executables: la lista de procesos que Agent Control iniciará, supervisará y reiniciará. Un tipo de agente sin esta sección se trata como una integración administrada (OHI): Agent Control maneja sus artefactos, pero delega la ejecución a otro agente.
• health: cómo Agent Control determina si el agente está en buen estado —mediante la presencia del proceso, una comprobación de extremo HTTP o ambos.
• filesystem: archivos o directorios individuales que Agent Control escribe en el host antes de iniciar el agente, como archivos de configuración o certificados.
• shared_filesystem: entradas escritas en una zona de depósito compartida accesible para otros agentes gestionados por la misma instancia de Agent Control. Utilizado por los tipos de agente OHI para entregar su configuración y binarios al agente de infraestructura.

Para obtener la referencia completa del esquema y todos los campos disponibles, consulte la Referencia del esquema de tipo de agente.

Obtener definiciones de tipo de agente

Agent Control obtiene las definiciones de tipo de agente de un registro OCI remoto, identificadas por namespace, name y version declarados en la sección de metadatos de la definición.

De forma predeterminada, Agent Control extrae de docker.io, usando el repositorio newrelic/agent-control-agent-types.

El Control del agente verifica la firma de cada definición con la clave pública de New Relic antes de descargarla.

Puede replicar este registro de la misma manera que los paquetes del agente.

Tipos de agentes vinculados

Dos tipos de agente están vinculados cuando uno escribe artefactos (configuración, binarios u otros archivos) en el sistema de archivos compartido y el otro está configurado para leer desde esas mismas rutas. El escritor puede no tener una sección executables, Agent Control administra sus artefactos, pero nunca inicia un proceso para él. En su lugar, el agente lector tiene la lógica incorporada para descubrir y ejecutar binarios y configuración desde una ruta conocida en el sistema de archivos compartido, lo que ejecuta de manera efectiva el complemento en nombre del escritor.

La raíz del sistema de archivos compartido es:

Todos los agentes administrados por la misma instancia de Agent Control comparten esta raíz. Los nombres de los subdirectorios se eligen por convención entre los tipos de agentes vinculados.

Integraciones en el host (OHI)

Las integraciones en el host (OHI) son el ejemplo principal de agentes vinculados en Agent Control; donde otros agentes tienen un proceso iniciado por Agent Control, los agentes de OHI no tienen un proceso propio y Agent Control nunca los inicia. Permite que Agent Control administre el ciclo de vida completo de la integración de New Relic Infrastructure, descargándola, configurándola, actualizándola y desinstalándola, mientras delega su ejecución al agente de infraestructura, que descubre y ejecuta los binarios de integración desde el sistema de archivos compartido.

La relación entre el agente de infraestructura y el agente de OHI

1. Cuando se instala un tipo de agente OHI, Agent Control descarga el binario de integración a través de OCI y escribe dos entradas en el sistema de archivos compartido:

   • Un archivo de configuración en infra-agent-ohi-configs/ (por ejemplo, nri-redis.yaml)
   • El binario de integración en infra-agent-ohi-binaries/ (por ejemplo, nri-redis)

2. El subagente del agente de infraestructura se configura con variables de entorno que lo apuntan a estos directorios compartidos:

   Variable	Ruta del sistema de archivos compartido	Objetivo
   NRIA_PLUGIN_DIR	…/infra-agent-ohi-configs	Descubrimiento de configuración de integración
   NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR	…/infra-agent-ohi-binaries	Descubrimiento de binarios de integración
   NRIA_SAFE_BIN_DIR	…/infra-agent-ohi-binaries	Ruta de ejecución de binarios permitida

3. El agente de infraestructura recoge la configuración y el binario en su siguiente ciclo de escaneo y comienza a ejecutar la integración.

   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

   Copia

Tipos de agentes admitidos

Soporte actual

La siguiente tabla muestra qué tipos de agente admite Agent Control y su disponibilidad en los distintos entornos.

Permisos requeridos por tipo de agente

La siguiente tabla enumera los permisos clave que requiere cada tipo de agente y los entornos donde se aplica.

Configuración de Fluent Bit en hosts

En los hosts, Fluent Bit no se despliega como su propio tipo de agente de nivel superior (consulte la tabla de compatibilidad anterior). En su lugar, cuando se habilita el reenvío de logs, el propio agente de infraestructura de New Relic genera y administra Fluent Bit, de la misma manera que cuando se instala de forma independiente. Agent Control solo cambia dónde residen en el disco el agente de infraestructura, sus datos y el binario y el plug-in de Fluent Bit.

Para saber cómo configurar el reenvío de logs en sí (sintaxis de logging.d/*.yml, entradas, filtros, atributos, etc.), consulte:

• Activar administración de logs
• Reenvío de logs con Fluent Bit

Dónde colocar su configuración

El único detalle específico de Agent Control es a dónde van los archivos de reenvío de logs: terminan en la carpeta logging.d del subagente, una entrada por fuente de logs, a través del campo config_logging de la configuración del agente de infraestructura. Establézcalo directamente en la configuración del subagente (por ejemplo, su local_config.yaml) y envíelo a 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

Dónde reside Fluent Bit y cómo se actualiza