Tipos de agente

Uma definição de tipo de agente é um arquivo YAML que descreve como o Agent Control deve identificar, baixar, configurar e executar um agente específico. Suas variáveis declaradas também formam o esquema de configuração que o Controle de Agentes expõe aos operadores ao implantar ou atualizar um subagente da frota. Cada definição consiste em três seções principais, metadata, variables e deployment, além de um campo protocol_version de nível superior que define a versão da linguagem de esquema na qual o arquivo é escrito.

Metadados

A seção de metadados identifica o tipo de agente: seu name, namespace, version, platform de destino (host ou kubernetes) e operating_system (necessário para tipos baseados em host). O Agent Control usa esses campos para endereçar de forma exclusiva a definição e enviá-la para o mecanismo de implantação correto.

Variáveis

A seção de variáveis declara as entradas configuráveis que os operadores podem definir ao adicionar um subagente à sua configuração. Cada variável tem um type (como string, bool ou yaml), um default opcional e uma lista variants opcional de valores aceitos. As variáveis são referenciadas em toda a seção de implantação usando ${nr-var:variable_name}.

Implantação

A seção de implantação descreve como o Agent Control instala e executa o agente na plataforma de destino. Ela é composta por várias subseções:

• packages: artefatos OCI para baixar antes que o agente inicie — normalmente o binário do agente ou o pacote de integração.
• executables: a lista de processos que o Agent Control iniciará, monitorará e reiniciará. Um tipo de agente sem esta seção é tratado como uma integração gerenciada (OHI): o Agent Control lida com seus artefatos, mas delega a execução para outro agente.
• health: como o Agent Control determina se o agente está íntegro — por meio da presença do processo, de uma verificação de endpoint HTTP ou de ambos.
• filesystem: arquivos ou diretórios individuais que o Agent Control grava no host antes de iniciar o agente, como arquivos de configuração ou certificados.
• shared_filesystem: entradas gravadas em uma zona de depósito compartilhada acessível a outros agentes gerenciados pela mesma instância do Agent Control. Usado por tipos de agente OHI para entregar sua configuração e binários ao agente de infraestrutura.

Para obter a referência completa do esquema e todos os campos disponíveis, consulte a Referência do esquema do tipo de agente.

Buscar definições de tipo de agente

O Agent Control busca definições de tipo de agente de um registro OCI remoto, identificado por namespace, name e version declarados na seção de metadados da definição.

Por padrão, o Controle do agente obtém de docker.io, usando o repositório newrelic/agent-control-agent-types.

O controle do agente verifica a assinatura de cada definição com a chave pública da New Relic antes de baixá-la.

É possível espelhar este registro da mesma forma que os pacotes de agente.

Tipos de agente vinculados

Dois tipos de agente são vinculados quando um grava artefatos (configuração, binários ou outros arquivos) no sistema de arquivos compartilhado e o outro é configurado para ler desses mesmos caminhos. O gravador pode não ter uma seção executables, o Agent Control gerencia seus artefatos, mas nunca inicia um processo para ele. Em vez disso, o agente leitor tem a lógica integrada para descobrir e executar binários e configurações de um caminho conhecido no sistema de arquivos compartilhado, executando efetivamente o complemento em nome do gravador.

A raiz do sistema de arquivos compartilhado é:

Todos os agentes gerenciados pela mesma instância do Agent Control compartilham esta raiz. Os nomes dos subdiretórios são escolhidos por convenção entre os tipos de agente vinculados.

Integrações no host (OHI)

As integrações no host (OHIs) são o principal exemplo de agentes vinculados no controle de agente; onde outros agentes têm um processo iniciado pelo controle de agente, os agentes OHI não têm processo próprio e o controle de agente nunca os inicia. Elas permitem que o Agent Control gerencie todo o ciclo de vida das integrações do New Relic Infrastructure, baixando, configurando, atualizando e desinstalando-as enquanto delega sua execução ao agente de infraestrutura, que descobre e executa os binários de integração do sistema de arquivos compartilhado.

A relação entre o agente de infraestrutura e o agente OHI

1. Quando um tipo de agente OHI é instalado, o Agent Control baixa o binário de integração via OCI e grava duas entradas no sistema de arquivos compartilhado:

   • Um arquivo de configuração em infra-agent-ohi-configs/ (por exemplo, nri-redis.yaml)
   • O binário de integração em infra-agent-ohi-binaries/ (por exemplo, nri-redis)

2. O subagente do agente de infraestrutura é configurado com variáveis de ambiente que o apontam para esses diretórios compartilhados:

   Variável	Caminho do sistema de arquivos compartilhado	Propósito
   NRIA_PLUGIN_DIR	…/infra-agent-ohi-configs	Descoberta de configuração de integração
   NRIA_CUSTOM_PLUGIN_INSTALLATION_DIR	…/infra-agent-ohi-binaries	Descoberta de binário de integração
   NRIA_SAFE_BIN_DIR	…/infra-agent-ohi-binaries	Caminho de execução de binário permitido

3. O agente de infraestrutura pega a configuração e o binário em seu próximo ciclo de verificação e começa a executar a integração.

   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

   Copiar

Tipos de agentes suportados

Suporte atual

A tabela a seguir mostra quais tipos de agente o Agent Control suporta e sua disponibilidade nos ambientes.

Permissões necessárias por tipo de agente

A tabela a seguir lista as principais permissões que cada tipo de agente exige e os ambientes onde ele se aplica.

Configuração do Fluent Bit em hosts

Em hosts, o Fluent Bit não é implantado como seu próprio tipo de agente de nível superior (consulte a tabela de suporte acima). Em vez disso, quando o encaminhamento de logs está ativado, o Fluent Bit é gerado e gerenciado pelo próprio agente de infraestrutura do New Relic, da mesma forma que quando é instalado de forma independente. O Agent Control altera apenas onde o agente de infraestrutura, seus dados e o binário e o plug-in do Fluent Bit residem no disco.

Para saber como configurar o próprio encaminhamento de logs (sintaxe logging.d/*.yml, entradas, filtros, atributos e assim por diante), consulte:

• Habilitar gerenciamento de logs
• Encaminhar logs com o Fluent Bit

Onde colocar sua configuração

O único detalhe específico do Agent-Control é para onde vão os arquivos de encaminhamento de logs: eles chegam na pasta logging.d do subagente, uma entrada por fonte de log, por meio do campo config_logging da configuração do agente de infraestrutura. Defina-o diretamente na configuração do subagente (por exemplo, seu local_config.yaml) e envie-o para o 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

Onde o Fluent Bit reside e como ele é atualizado