APM

Rastreamento distribuído, métricas RED (taxa, erros e duração) e mapa de dependências dos serviços dos seus hosts. O nível 1 usa eBPF e não muda nada na aplicação; o nível 2 carrega o instrumentador oficial da linguagem e só entra com plano aprovado e reinício feito por você.

Níveis de instrumentação

Um processo que já tem SDK ou agente OpenTelemetry nunca recebe o nível 2, mas continua no eBPF: o SDK segue mandando para o destino atual (Elastic, Jaeger...) e o argus-apm observa o processo de fora, sem interferir. Serviços sem requisições de entrada (workers, jobs) mostram o RED das chamadas que fazem.

Enviar de um OpenTelemetry Collector que já existe

Acrescente um exporter ao pipeline traces do collector, mantendo o exporter atual. Use o token do site e o agent_id de um host do mesmo site:

exporters:
  otlphttp/argus:
    endpoint: https://<api-do-argus>/otlp
    compression: gzip
    headers:
      Authorization: "Bearer ${env:ARGUS_SITE_TOKEN}"
      X-Argus-Agent-Id: "<agent_id>"
service:
  pipelines:
    traces:
      exporters: [seu-exporter-atual, otlphttp/argus]

Só traces são aceitos, e a sanitização é a mesma do agente. Se o serviço também é observado pelo eBPF, o RED conta só o eBPF; para ficar só com o SDK, exclua o serviço na política.

Linguagens

Abaixo da versão mínima o serviço continua no nível 1.

Instalação

O APM é instalado junto com o agente, com um token de site. Nada é coletado até a política do site ligar o APM no painel (APM → Configuração).

curl -fsSL https://argus-homolog.eulabs.net.br/install-argus-agent.sh | sudo bash -s -- \
  --token <token-do-site> --with-apm

No painel, Admin → Projetos e sites → Adicionar nó gera esse comando: marque APM (eBPF) e, para ligar os traces entre serviços, Propagação de contexto (--apm-propagation). Em Docker Swarm, rode o comando em cada nó: o eBPF do host instrumenta os containers sem mudar as imagens. O receiver local do APM usa 127.0.0.1:14317/14318, sem conflito com um OpenTelemetry Collector já publicado em 4317/4318.

O componente roda como argus-apm.service, com capabilities mínimas, até 1,5 GiB de memória (contando os mapas eBPF) e meio core. Kernel Linux 5.8 ou mais novo com BTF (RHEL/derivados 4.18 com backports), amd64 ou arm64. O agente confere a compatibilidade do host e mostra o resultado no painel.

O agente se protege sozinho para o APM nunca derrubar um servidor. Em kernel sem uprobe_multi (anterior ao 6.6), os serviços Go são observados pelo rastreador genérico do kernel, mais leve, com menos detalhe de rota e SQL. Se a carga do host subir demais com o APM ligado, o agente suspende o APM por 15 minutos (dobrando até 4 horas) e o painel mostra "Suspenso (carga)". Ao ligar o APM, cada nó começa num momento diferente, em até 5 minutos.

Ativação do nível 2

Três condições, todas obrigatórias:

1. o host permite: instale com --allow-apm-activation;
2. o administrador do Argus habilitou a ativação;
3. existe um plano aprovado para o serviço: por um operador, na janela de manutenção, ou automaticamente para os serviços que a política do site autoriza.

O agente baixa o instrumentador por https, confere a assinatura, grava /etc/systemd/system/<serviço>.d/90-argus-apm.conf e roda só systemctl daemon-reload. O Argus nunca reinicia o seu serviço: o painel mostra “aguardando reinício” até você reiniciar. Se a unit já define a mesma variável, o plano é recusado. Para desfazer, use o botão de rollback do plano ou, no host, argus-agent apm rollback <serviço>; vale no próximo reinício.

Perfil de CPU (profiling contínuo)

Mostra quais funções gastam CPU em cada serviço, para Go e para as outras linguagens, sem mudar código e sem reiniciar a aplicação. Em Go os nomes das funções aparecem mesmo em binário compilado com -ldflags="-s -w". O recurso está em fase inicial (alpha), vem desligado e é ligado por política.

• Ligar: em APM > Configuração, ative “Profiling contínuo (CPU)” na política do site (ou do ambiente). Vale para o host inteiro e exige o eBPF ligado. A amostragem é de 19 por segundo.
• Ver: na página do serviço, escolha “Perfil (CPU)”. Aparecem o flame graph (largura = tempo de CPU), as funções que mais gastam (no topo da pilha e no total), o filtro por instância e a comparação com o período anterior. No detalhe de um span, “Ver perfil de CPU” abre o perfil da mesma janela de tempo (±30 s). É uma correlação por tempo, não pela requisição exata.
• Privacidade: só os processos dos serviços observados são perfilados; a pilha de qualquer outro processo do host é descartada antes de sair dele. Variáveis de ambiente não são enviadas.
• Requisitos: kernel 5.4 ou mais novo (5.5 em arm64). Em kernel mais antigo o painel marca o recurso como indisponível naquele host e o resto do APM continua.
• Vetar num host: apm.profiling.allowed: false no config.yml do agente; apm.profiling.max_frequency_hz limita a amostragem.

Containers e clusters

• Docker e Swarm: o argus-apm.service no host enxerga os containers pelo eBPF. Para o nível 2, o painel mostra o override do Compose ou o trecho da stack; quem aplica é você.
• Kubernetes: com o agente no host, o mesmo serviço systemd. Em cluster gerenciado, um DaemonSet aplicado pelo seu GitOps. Para o nível 2, o painel sugere o patch ou a anotação do OpenTelemetry Operator; o Argus não aplica nada no cluster.
• Métricas por container e pod: CPU, memória e rede de cada container, nos painéis de Dashboards (fonte Containers e pods). Em hosts Docker/Swarm, ligue com apm.container_metrics: true no config.yml do agente, um host de cada vez. No Kubernetes, o DaemonSet já coleta pelo kubelet.

Privacidade

Antes de sair do host: query string das URLs removida, headers de autorização, cookie e token removidos, SQL sem literais (os valores viram ?) e atributos truncados. O envio usa o token do site; a empresa e o site dos dados vêm do token, nunca do que a aplicação declara. Cada pessoa vê só os traces do seu escopo.

Logs, bancos e infraestrutura

• Logs: no detalhe do span, separados em “correlação exata” (o log traz o trace_id), “mesma instância e período” e “mesmo host e período”. O trace_id só aparece quando o formato de log da aplicação inclui o campo.
• Bancos: o span de consulta leva ao banco monitorado; a estatística agregada da mesma consulta e os locks do período aparecem com rótulo próprio, nunca como causa. O plano de execução é estimado, sob demanda, por um operador.
• Infraestrutura: CPU, memória, disco, OOM, reinícios e deploys da instância no período do trace.

Desligar

Mude a política do site para “somente descoberta” com eBPF desligado: o agente para o argus-apm. Os drop-ins do nível 2 saem pelo rollback dos planos e os dados expiram pela retenção configurada.