A forma tradicional de perfilar um problema de produção tem uma dependência desconfortável: você já tem que suspeitar disso. Algo parece lento, você anexa um perfilador, você tenta reproduzir a condição, e — se você for sortudo e o problema ainda está acontecendo — você captura dados. O modo de falha é óbvio e comum. O incidente aconteceu às 3 da manhã, durou quatro minutos, e quando alguém olhou, a evidência se foi. Você adiciona logging, espera isso recorrer, e aguarda.
eBPF mudou a economia o bastante para inverter aquele fluxo de trabalho. Porque programas eBPF executam dentro do kernel em uma sandbox verificada, eles conseguem observar syscalls, agendamento e stack traces através de cada processo em uma máquina em overhead baixo o bastante — consistentemente menos de 1% — para deixar executando permanentemente. Isto transforma perfilamento de algo que você começa em algo que você consulta: os dados para 3 da manhã já existe. Este guia cobre aquele shift através de Parca Agent para perfilamento contínuo, e uma aplicação mais nova que emergiu conforme agentes autônomos proliferam — usando a mesma visibilidade em nível de kernel para ver o que um agente de IA realmente fez, via ferramentas como AgentSight.
Por que eBPF tornou sempre-ativo viável
A razão técnica de perfilamento contínuo ser impraticável antes é que as opções antigas todas impostas um imposto que você não pagaria permanentemente. Perfiladores de sampling baseados em perf são baratos mas requerem setup por alvo e produzem dados que você deve gerenciar. Perfiladores instrumentados requerem mudanças de código e adicionam sobrecarga por-chamada. Agentes específicos de linguagem cobrem um runtime e frequentemente introduzem seu próprio custo de desempenho. Nenhum deles eram coisas que você executaria em cada processo em cada nó para sempre.
A contribuição de eBPF é que programas executam em espaço de kernel, então coletar um stack trace não requer context-switching para um agente userspace para cada sample, e o verificador do kernel prova estaticamente que o programa não consegue travar o sistema ou loop para sempre antes de ser permitido carregar. O resultado é visibilidade em nível de kernel com garantias de segurança e overhead no ruído. Crucialmente é também zero-instrumentação: você não modifica, recompila ou reinicia as aplicações sendo perfiladas, que remove o atrito organizacional que matou a maioria das tentativas anteriores ("precisávamos de cada equipe para adicionar um agente").
Há um pré-requisito real vale a pena declarar: isto depende de um kernel razoavelmente moderno com suporte BTF, e qualidade de desembrulho de stack depende de seus binários terem símbolos. Binários de produção stripped produzem perfis cheios de endereços hex, que é um problema solúvel mas um que você deveria resolver antes de concluir que a ferramenta não funciona.
Perfilamento contínuo na prática
Parca Agent é a expressão mais clara da ideia. Deployed como um DaemonSet em Kubernetes (ou um processo em um nó), ele amostra stack traces de cada processo naquele nó, continuamente, rotula-os com pod, container e metadados de namespace, e envia-os para um servidor onde são armazenados como métricas — consultáveis por intervalo de tempo e rótulo.
Aquele modelo de armazenamento é o que o torna útil em vez de meramente interessante. Porque perfis são séries de tempo rotuladas, você consegue fazer perguntas que perfilamento sob-demanda não consegue. O que estava consumindo CPU no namespace de pagamentos entre 03:04 e 03:08? O perfil existe; você filtra para a janela. Ainda mais valioso é comparação: diff o perfil de antes de um deployment contra depois, e a regressão aparece como uma função que cresceu. Você não precisava prever que desejaria o perfil "antes" — coleta contínua significa que sempre está lá.
Parca lida com stacks de linguagem mista, que importa mais do que soa. Um serviço moderno pode ser Go chamando em bibliotecas C, ou Python invocando extensões nativas, e um perfil que resolve apenas uma camada conta uma história enganosa. Desembrulho em nível de kernel vê a stack inteira. Para análise profunda única você ainda alcançará perf ou async-profiler — perfilamento contínuo otimiza para cobertura e história, não detalhe máximo por-execução — mas a pergunta cotidiana de "em o que este cluster está gastando CPU" é respondida continuamente e barato.
O problema mais novo: o que o agente fez?
A segunda aplicação é mais nova e, em 2026, crescentemente premente. Equipes estão executando agentes de codificação autônomos e agentes LLM com acesso de ferramenta em sistemas reais. Estes agentes leem arquivos, executam comandos, instalam pacotes e fazem chamadas de rede. A observabilidade daqueles sistemas fornece é em nível de aplicação: prompts, chamadas de ferramenta, contagens de token, spans. Ferramentas como Langfuse e Arize Phoenix fazem isto bem e são genuinamente úteis para entender raciocínio de um agente.
Mas rastreamento em nível de aplicação tem uma limitação estrutural: mostra o que a estrutura do agente escolheu relatar. Se uma ferramenta executa um comando shell, o rastreamento registra a string de comando — não os dezessete processos que o comando spawnou, os arquivos que tocaram, ou o host que contactaram. Se o agente é comprometido por injeção de prompt e leva uma ação fora de seu escopo pretendido, o rastreamento mostra a ação que narrou, que é exatamente a fonte de verdade errada para uma pergunta de segurança.
AgentSight aplica eBPF aqui: observa o comportamento real de sistema do agente no nível de kernel — execução de processo, acesso a arquivo, conexões de rede — com nenhuma instrumentação do agente em tudo. O agente não consegue omitir ou falsificar esses eventos porque não é o que está reportando-os. Para um agente de codificação operando em um repositório, você obtém a resposta real a "quais arquivos ele modificou," "o que ele executou," e "ele alcançou fora do workspace."
A postura correta é que estas são camadas complementares, não competidoras. Rastreamento de aplicação diz você a intenção e raciocínio do agente; rastreamento de kernel diz seus efeitos. Correlacioná-los por timestamp dá você ambas as metades: isto é o que o agente estava tentando fazer, e isto é o que realmente aconteceu na máquina. Para qualquer coisa com permissões reais, ter apenas a primeira metade é uma lacuna.
Segurança, não apenas desempenho
Aquele framing aponta no mais amplo uso. A mesma base eBPF respalda ferramentas de segurança de runtime — Tracee, Falco, Tetragon — que observam por comportamento suspeito em nível de kernel e, no caso de Tetragon, conseguem enforçar política in-kernel. Uma vez que você está coletando eventos de processo, arquivo e rede em cada nó, a diferença entre "observabilidade" e "detecção" é principalmente quais perguntas você faz dos dados.
Para workloads de agente especificamente, aquela convergência é útil. As perguntas "por que isto é lento," "o que o agente mudou," e "qualquer coisa escapou de sua sandbox" são todas respondidas do mesmo fluxo de eventos. Praticamente, isto significa uma organização deployando agentes com acesso de sistema deveria tratar visibilidade em nível de kernel como parte do deployment, não um pensamento posterior — ela é a única camada que produz evidência auditável de o que um processo autônomo realmente fez.
O caveat honesto é volume. Rastreamento em nível de kernel consegue gerar fluxos de eventos enormes, e naïvely logar cada syscall em um nó ocupado vai sobrecarregar seu armazenamento e sua habilidade encontrar qualquer coisa. Filtragem na fonte — por caminho, por processo, por tipo de evento — não é uma otimização mas um requisito, e isto é aonde a maioria do trabalho operacional em estas ferramentas vive.
Lendo um perfil sem enganar a si mesmo
Perfilamento contínuo produz muitos dados, e há algumas formas confiáveis de lê-lo errado. Vale a pena saber antes que você age em um flame graph.
Largura é samples, não latência wall-clock. Um perfil de CPU mostra para onde tempo de CPU foi. Se seu serviço é lento porque está esperando — em um banco de dados, uma lock, uma chamada de rede — o perfil de CPU pode parecer perfeitamente saudável, porque uma thread bloqueada consome nenhum CPU. Isto é o misdiagnosis único mais comum: concluir não há problema porque o perfil de CPU é flat, quando o problema é tempo off-CPU. Wall-clock ou perfilamento off-CPU responde aquela pergunta em vez disso.
Hotspots agregados não são necessariamente seu problema de latência. Uma função consumindo 30% de CPU de cluster pode ser inteiramente esperada background work — serialização, compressão, garbage collection. O sinal interessante é geralmente uma mudança: esta função era 5% semana passada e é 30% agora. Isto é por que comparação importa mais que ranking absoluto, e por que coleta contínua bate um snapshot único.
Qualidade de símbolo molda conclusões. Símbolos faltando fazem stacks colapsar em endereços hex desajudadores, e pior, eles conseguem misatribuir tempo para o frame resolvível mais próximo — produzindo uma resposta confiante, errada. Se um perfil culpa uma função que não faz sentido, suspeite desembrulho antes de suspeitar o código.
Sampling tem um piso. Uma função que executa frequentemente mas muito brevemente pode ser subrrepresentada relativa a seu custo verdadeiro, e eventos raros-mas-caros podem não aparecer em tudo em uma janela curta. Coleta contínua atenua isto agregando ao longo de períodos longos, que é outro argumento para sempre-ativo sobre sob-demanda.
O hábito prático: use o perfil para formar uma hipótese, então confirme-a com uma medição focada antes de você gastar um sprint otimizando.
Adotando isto sensatamente
Uma sequência pragmática evita a falha comum de deployar tudo e afogar. Comece com perfilamento contínuo em um subconjunto de nós. É a introdução de menor risco, entrega valor imediatamente (você achará algo surpreendente na primeira semana), e ensina-lhe como seus kernels e símbolos se comportam antes de qualquer coisa depender disso. Confirme que stacks resolvem para nomes de função reais; corrija disponibilidade de símbolo se eles não fazem.
Então adicione fluxos de trabalho de comparação, porque isto é aonde o payoff concentra: fio perfilamento diffing em seu processo de release para que uma regressão de CPU seja capturada como uma mudança de perfil em vez de como um alerta de latência três dias depois.
Adicione rastreamento em nível de agente quando você realmente executa agentes com acesso de sistema. Se seus agentes apenas chamam APIs e retornam texto, rastreamento de kernel é overkill. Se eles executam comandos, escrevem arquivos, ou operam em repositórios, a lacuna de visibilidade é real e vale a pena fechar.
E filtre agressivamente do começo. Decida antecipadamente quais caminhos, processos e tipos de evento importam, e exclua o resto. É longe mais fácil alargar um filtro estreito depois que retrofit filtragem para um firehose que você já está armazenando.
Finalmente, mantenha as ferramentas sob-demanda afiadas. Perfilamento contínuo diz você que uma função ficou hot e quando; perf, bpftrace e async-profiler permanecem melhor para o deep dive em por quê. O fluxo de trabalho que funciona é dados contínuos para detecção e história, ferramentas focadas para diagnóstico.
O resumo
eBPF mudou observabilidade de "anexe um perfilador quando você suspeita de um problema" para "os dados já existem, consulte-o," porque execução em nível de kernel com uma sandbox verificada tornou coleta sempre-ativa custo menos de 1% e requerer nenhuma mudança de aplicação. Parca Agent entrega isto como perfilamento contínuo, consultável por rótulo, de linguagem mista de CPU cujo superpoder real é comparar antes e depois. A nova fronteira é aplicar a mesma visibilidade aos agentes autônomos: AgentSight mostra o que um agente realmente fez em nível de syscall, fechando a lacuna deixada por rastreamentos de aplicação que apenas reportam o que o agente escolheu narrar. Comece com perfilamento em poucos nós, verifique seus símbolos, construa comparação em releases, adicione rastreamento de agente quando agentes tocam sistemas reais, filtre duro do dia um, e mantenha perf e bpftrace para os deep dives.
Referências e Recursos
Ferramentas
Fundo e análise
- 8 Melhores Ferramentas de Rastreamento eBPF de Código Aberto em 2026 — Better Stack
- eBPF.io — o que é eBPF
- Brendan Gregg em ferramentas de desempenho eBPF
Cheatsheets 1337skills relacionados