Configurar um Proxy para o Agente eBPF do New Relic

Se o seu ambiente roteia o tráfego de saída por um proxy corporativo, você pode configurar o New Relic eBPF agent para enviar telemetria OTLP por esse proxy. Esta página explica como configurar o suporte a proxy em hosts Linux e clusters do Kubernetes, os requisitos do servidor proxy e como solucionar problemas comuns.

Como funciona o suporte a proxy

O eBPF agent usa o suporte a proxy HTTP integrado do gRPC. Quando você configura um proxy, o agente:

1. Conecta-se ao servidor proxy.
2. Envia uma requisição HTTP CONNECT para abrir um túnel para o endpoint OTLP da New Relic.
3. Realiza um handshake TLS com o endpoint OTLP através desse túnel.
4. Adiciona um cabeçalho Proxy-Authorization: Basic <base64> se você forneceu credenciais.

Requisitos do servidor proxy

Seu servidor proxy deve suportar:

• O método HTTP CONNECT (necessário para o tunelamento TLS para o endpoint OTLP).
• Tunelamento para a porta 443 (o endpoint OTLP usa HTTPS).
• Autenticação Básica HTTP, se você usar acesso de proxy autenticado.

Servidores proxy suportados

Limitações de caracteres de credenciais

Ao configurar credenciais de proxy, use apenas os seguintes caracteres:

• Nome de usuário: letras minúsculas (a–z), dígitos (0–9), hífen (-), sublinhado (_), ponto (.) e til (~). Letras maiúsculas não são permitidas.
• Senha: letras (a–z, A–Z), dígitos (0–9), hífen (-), sublinhado (_), ponto (.) e til (~).

Os seguintes caracteres não são permitidos no nome de usuário ou na senha: @, :, /, ?, #, [, ], !, $, &, ', (, ), *, +, ,, ;, =, %, espaços e outros caracteres especiais.

Se as credenciais de proxy existentes usarem caracteres não permitidos, peça ao administrador do proxy para criar uma conta de proxy dedicada para o eBPF agent que use um nome de usuário alfanumérico em letras minúsculas e uma senha simples.

Precedência de configuração

Quando mais de uma fonte define um proxy, o agente os aplica nesta ordem:

• otlpProxy.url — URL completa do proxy.
• otlpProxy.* — Configurações individuais de proxy (host, port, scheme, user, password).

Essa precedência se aplica tanto ao host Linux quanto às implantações do Kubernetes.

Configurar um proxy

otlpProxy:
  host: "proxy.corporate.com"
  port: 8080
  scheme: "http"
  user: "myuser"
  password: "mypassword"
  url: ""
  existingSecret: ""

$
kubectl create secret generic ebpf-proxy-creds \
>
  --namespace newrelic \
>
  --from-literal=proxy-user=myuser \
>
  --from-literal=proxy-password=mypassword

$
helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yaml

otlpProxy:
  host: "proxy.corporate.com"
  port: 8080
  scheme: "http"
  user: "myuser"
  password: "mypassword"
  url: ""

$
sudo chmod 600 /etc/newrelic-ebpf-agent/newrelic-ebpf-agent.yaml
$
sudo systemctl restart newrelic-ebpf-agent

Verifique sua configuração de proxy

Após configurar o proxy, valide se o agente está utilizando-o conforme o esperado.

Verificar o log do agente

Verifique o log do agente para mensagens relacionadas a proxy:

$
journalctl -u newrelic-ebpf-agent | grep -i proxy

Procure uma destas mensagens:

• Using proxy for OTLP endpoint: <endpoint> via http://<host>:<port> — O proxy está habilitado.
• Proxy authentication enabled (username: <user>) — A Autenticação Básica está configurada.
• Direct connection to OTLP endpoint (no proxy configured) — Nenhum proxy está em uso.

Testar a conectividade do proxy

Use curl para confirmar que seu proxy suporta o método HTTP CONNECT e pode alcançar o endpoint OTLP da New Relic:

$
# Unauthenticated proxy
$
curl -v -x http://proxy.example.com:8080 https://otlp.nr-data.net
$

$
# Authenticated proxy
$
curl -v -x http://user:pass@proxy.example.com:8080 https://otlp.nr-data.net

Uma resposta bem-sucedida inclui:

< HTTP/1.1 200 Connection established
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!

Se o agente não estiver roteando pelo proxy ou você encontrar erros, consulte Solucionar Problemas do Proxy eBPF.

Considerações de segurança

Ao rotear o agente através de um proxy, tenha o seguinte em mente:

• Os dados de telemetria permanecem criptografados com TLS de ponta a ponta. O proxy vê apenas um túnel criptografado para o endpoint OTLP. Ele nunca tem acesso aos seus dados.
• As credenciais de proxy são enviadas em texto simples para o proxy porque o agente não suporta o esquema de proxy https://. Use autenticação de proxy apenas em uma rede confiável entre o agente e o proxy. Se você precisar de transporte criptografado entre o agente e o proxy, execute o proxy em localhost ou use uma VPN.
• O agente nunca grava senhas em seus logs. O nome de usuário pode aparecer em linhas de log como Proxy authentication enabled (username: <user>) para depuração.
• As implantações do Kubernetes devem usar existingSecret em vez de credenciais inline para manter as senhas de proxy fora do seu arquivo values.yaml e do controle de código-fonte.