eBPF agente práticas recomendadas guia

O agente eBPF New Relic utiliza a tecnologia eBPF para fornecer funcionalidade APM em um único agente com instrumentação de código zero. Essa abordagem capacita equipes de engenharia de plataforma, eliminando a necessidade de coordenação com equipes de aplicativos para implantação de monitoramento.

Quando usar o eBPF APM

• Implantação em larga escala: Quando você tem muitos aplicativos que precisam de monitoramento implantado em escala e exigem métrica "boa o suficiente" sem a sobrecarga de agente de linguagem individual.
• Carga de trabalho desconhecida ou imutável: Quando a workload que você deseja monitorar está escrita em uma linguagem de programação desconhecida e/ou não pode ser modificada.
• Eficiência da engenharia de plataforma: Quando você deseja implantar monitoramento em escala sem coordenar com equipes de aplicativos individuais.
• Ambientes focados em Linux: Quando você não precisa monitorar a plataforma Windows, pois o eBPF funciona de forma excelente no Linux, tanto em ambientes Kubernetes quanto em ambientes host.
• Sem necessidade distributed tracing : Quando suas necessidades de monitoramento não exigem recursos distributed tracing.

Comparação entre eBPF e APM tradicional

Entender as diferenças entre o eBPF APM e os agentes de APM tradicionais ajuda você a escolher a abordagem correta:

Perspectiva da fonte de dados

O eBPF APM muda a perspectiva de monitoramento da camada de aplicação para a camada do kernel:

práticas recomendadas para implantação

Complementar o APM tradicional

Use o agente eBPF para complementar os agentes de linguagem de APM para uma cobertura abrangente. Isso oferece cobertura completa de APM com coexistência entre o APM eBPF e os agentes de APM, sem ingestão dupla de dados.

Abordagem recomendada:

• Agente de linguagemAPM : Use para seus aplicativos mais críticos que exigem insights de nível profundo, distributed tracing ou instrumentação personalizada.
• eBPF APM: Use para cobrir todo o resto, incluindo serviços não instrumentados, aplicativos de terceiros, e para descobrir/relatar continuamente novos serviços.

Adicionar métrica de rede para um contexto mais profundo

O agente eBPF também pode fornecer métricas de rede granulares (TCP, DNS, etc.) para dar visibilidade fora dos limites da sua aplicação. Este recurso é complementar e pode ser usado com ou sem o eBPF APM. Para mais informações, consulte network-metrics.

As seguintes opções de implantação estão disponíveis:

Adicionar coleta de logs para MELT completo

O agente eBPF também pode coletar logs de aplicativo e enriquecê-los com metadados da New Relic por padrão, sem implantar um encaminhador de logs separado. Essa capacidade é executada no mesmo agente, portanto, é possível ativá-la junto com o eBPF APM e métricas de rede sem implantar nada extra. Para mais informações, consulte eBPF logs.

Utilize reportLogs: "auto" para evitar a coleta duplicada de logs automaticamente: o agente eBPF recua de um agente APM apenas se esse agente estiver coletando logs ativamente por conta própria, e recua totalmente sempre que um agente OpenTelemetry for anexado. Utilize "true" apenas quando for confirmado que nenhum outro agente está relatando logs para essa entidade.

Recomendações de implementação

• Comece com o APM eBPF para escalabilidade: Se você precisa implantar monitoramento em escala em muitas aplicações e deseja métricas "boas o suficiente" sem uma coordenação complexa, comece com o APM eBPF.

• Adicione métricas de rede para visibilidade completa: Assim que o APM eBPF for implantado, considere adicionar métricas de rede eBPF para obter visibilidade além dos limites da aplicação para capacidades abrangentes de solução de problemas.

• Adicionar coleta de logs para uma resolução de problemas unificada: Quando estiver pronto, ative os logs do eBPF para coletar logs de aplicativo sem implantar um encaminhador de logs separado.

Amostragem de dados e ajuste fino

Os agentes de linguagem do APM limitam os eventos de transação com um reservatório fixo, por padrão 10.000 eventos por minuto (configurado com transaction_events.max_samples_stored). O agente eBPF não usa um único limite fixo por minuto. Em vez disso, ele faz a amostragem de cada tipo de telemetria de forma diferente, portanto, entender como cada tipo se comporta ajuda a controlar o volume de dados e os custos sem perder os sinais que são importantes.

Como funciona a amostragem span

O agente eBPF não limita os spans a um número fixo por minuto. Para cada protocolo, ele exporta apenas os spans que ultrapassam um limite definido:

• Limite de latência (samplingLatency): exporta spans mais lentos que o percentil escolhido para uma determinada rota. O padrão é p50 (a mediana). Aumente-o para p90 ou p99 para manter apenas a cauda mais lenta e reduzir o volume de dados; diminua-o para p1 ou p0 para manter quase todos os spans e aumentar a visibilidade. Qualquer percentil de p0 a p99 é aceito.
• Limite de taxa de erros (samplingErrorRate, HTTP): um valor de 1 a 100. Quando a taxa de erros de uma rota excede esse limite, os spans dessa rota são exportados para que as falhas nunca sejam descartadas por amostragem. Deixe em branco para desativar a exportação baseada em erros.

Controlando spans não vinculados

Os spans que o agente captura, mas não consegue associar a um pai, são chamados de spans não vinculados. Eles são limitados por protocolo por max_unlinked_spans (padrão 100; defina como 0 para desativar o limite). A configuração unlinked_spans_error_quota_percentage (padrão 30) reserva parte desse orçamento para spans de erro, para que as falhas permaneçam visíveis mesmo quando os spans normais chegam primeiro.

Exemplos de ajuste

A amostragem é configurada no arquivo Helm values.yaml (Kubernetes) ou em /etc/newrelic-ebpf-agent/newrelic-ebpf-agent.yaml (host Linux). As chaves são idênticas para ambos.

protocols:
  global:
    max_unlinked_spans: 100          # 0 disables the cap
    unlinked_spans_error_quota_percentage: 30
  http:
    enabled: true
    spans:
      enabled: true
      samplingLatency: "p90"         # keep only slower requests, less data
      samplingErrorRate: "5"         # always keep routes with >5% errors
logDataFilters:
  applicationLogReporting:
    maxSamplesPerMinute: 10000         # APM-equivalent reservoir for logs

Recomendações

• Para maximizar a visibilidade do trace: diminua samplingLatency para p0 e defina um samplingErrorRate baixo, mas espere uma ingestão maior.
• Para reduzir os dados: aumente samplingLatency (por exemplo, p90 ou p99), desative totalmente os protocolos indesejados (ou apenas spans.enabled: false para manter apenas a métrica do protocolo) e diminua maxSamplesPerMinute para logs.
• Tenha a métrica em mente: a métrica não é afetada pela amostragem de spans. Desative um protocolo inteiro apenas quando seus dados não forem mais necessários.

Artigos relacionados