Importante
O Agent Control e o New Relic Control estão disponíveis para o público geral para Kubernetes. O suporte para hosts Linux e Windows está no programa de prévia pública, conforme nossas políticas de pré-lançamento.
Visão geral
O agente Control fornece uma plataforma única e unificada para gerenciar uma ampla variedade de agentes New Relic e OpenTelemetry em suas frotas. Ao centralizar o gerenciamento, você pode implantar, configurar e atualizar sua instrumentação com facilidade.
Embora o Agent Control seja projetado para suportar tanto ambientes Kubernetes quanto ambientes baseados em host, o suporte para tipos específicos de agentes varia. A tabela a seguir fornece uma visão geral abrangente de quais agentes podem ser gerenciados pelo Agent Control e seu status de suporte nos ambientes.
Suporte atual
| Tipo de agente | Suporte ao Kubernetes | Suporte a host Linux | Suporte a host Windows |
|---|---|---|---|
| Agente de infraestrutura New Relic | ✅ Sim | Prévia pública | Prévia pública |
| Collector OpenTelemetry New Relic (NRDOT) | ✅ Sim | ✅ Sim | ⚠️ Experimental |
| Fluent Bit | ✅ Sim | 🚫 Não | 🚫 Não |
| Agente New Relic Prometheus | ✅ Sim | 🚫 Não | 🚫 Não |
| Agente eBPF New Relic | ✅ Sim | ⚠️ Experimental | 🚫 Não |
| agente APM (.NET, Java, Node, Python, Ruby) | 🚫 Não | 🚫 Não | 🚫 Não |
Importante
Permissões específicas do agente: o Controle do agente foi projetado para fornecer gerenciamento de permissões flexível. Embora o próprio Agente Control exija um certo nível de acesso para funcionar, as permissões que ele concede a cada agente são adaptadas às suas necessidades específicas. Abaixo, você encontra uma análise das permissões necessárias para cada tipo de agente.
Permissões necessárias por tipo de agente
| Tipo de agente | Permissões de chave necessárias | Ambiente |
|---|---|---|
| Agente de infraestrutura New Relic | Acesso em nível de host para o sistema métrica e acesso API Kubernetes para dados cluster . | Kubernetes / baseado em host |
| Collector OpenTelemetry New Relic (NRDOT) | As permissões dependem de receptores e exportadores específicos. Geralmente requer acesso à API do Kubernetes para descoberta de serviços. | Kubernetes / baseado em host |
| Fluent Bit | Acesso de leitura aos logs de pod e contêiner. | Kubernetes |
| Agente New Relic Prometheus | Permissões para descobrir e acessar o ponto de extremidade de serviço dentro do cluster para extração de métricas. | Kubernetes |
| Agente eBPF New Relic | Privilégios elevados (por exemplo, CAP_SYS_ADMIN) para carregar programas eBPF no kernel do host. | Kubernetes, hosts Linux (experimental) |
| agente APM (.NET, Java, Node, Python, Ruby) | Atualmente não suportado pelo agente Control. | N/A |
O NRDOT em hosts Windows é experimental
O New Relic OpenTelemetry Collector (NRDOT) no Windows está disponível, mas não é oficialmente testado ou documentado pela equipe do NRDOT. A configuração padrão incluída é projetada para Linux e pode gerar avisos ou erros no Windows (por exemplo, de caminhos filelogreceiver). Nenhuma configuração padrão é incluída para Windows — você deve fornecer sua própria configuração de coletor. Use o NRDOT no Windows apenas em ambientes não críticos ou de teste até que o suporte completo ao Windows seja lançado.
O eBPF em hosts Linux é experimental
O agente eBPF da New Relic requer dependências de nível de kernel (como linux-headers correspondente à versão do kernel em execução) que o Agent Control não consegue resolver automaticamente em hosts Linux. Se essas dependências estiverem ausentes ou incompatíveis, a implantação pode falhar sem um erro claro. O suporte ao eBPF em hosts Linux está disponível para ambientes Kubernetes apenas em produção. Use o eBPF em hosts Linux apenas em ambientes não críticos ou de teste.
O eBPF não é suportado em hosts Windows.