Profiling contínuo em produção: perfis de amostragem sempre ativos e o que eles respondem

O que é

A documentação do Parca define profiling contínuo como a coleta sistemática de perfis (CPU, memória, I/O e outros) de programas, seguida do armazenamento e da consulta desses perfis ao longo do tempo. A unidade armazenada é uma série de perfis, identificada pelo tipo de perfil e por labels de chave/valor, e consultada com uma linguagem de seletores de labels. O Parca explica por que isso pode rodar de forma permanente: ele usa profiling por amostragem, que registra um stack trace a intervalos em vez de instrumentar cada chamada, e por isso tem overhead baixo o suficiente para ficar sempre ativo em produção. O Grafana Pyroscope se descreve da mesma forma, como um sistema de agregação de profiling contínuo que correlaciona perfis com métricas, logs e traces.

Os perfis vêm de três tipos de fonte: endpoints de runtime (o net/http/pprof do Go registra handlers em /debug/pprof/ que servem perfis de CPU durante o número de segundos solicitado, além de perfis de heap, goroutine, block e mutex), SDKs que enviam perfis de dentro do processo e agentes eBPF que fazem o profiling de todos os processos de um host sem exigir alterações na aplicação.

Por que importa

Um perfil avulso responde a "onde o tempo está sendo gasto agora". Um repositório contínuo responde às perguntas que surgem na operação: o que mudou entre a versão implantada ontem e a de hoje, qual função custa mais CPU somando todas as instâncias, por que a memória cresce ao longo de uma semana e o que o processo estava fazendo às 03:12, quando a latência subiu. Essas perguntas não podem ser respondidas coletando um perfil depois do ocorrido.

Como aplicar

• Comece pelos perfis de CPU e de alocação dos serviços que dominam o custo ou a latência; acrescente perfis de mutex e block quando houver suspeita de contenção (o Go só os serve depois que runtime.SetBlockProfileRate ou runtime.SetMutexProfileFraction tiver sido chamado).
• Atribua aos perfis labels de serviço, versão e instância, para que duas versões possam ser comparadas como a diferença entre dois flame graphs.
• Associe os endpoints de profiling do runtime a localhost ou a uma porta privada; o exemplo em Go os serve em localhost:6060, e um scraper os acessa pela rede privada.
• Mantenha curta a retenção dos perfis brutos e use as séries agregadas para analisar tendências.
• Verifique o overhead em uma cópia de staging sob carga realista antes de habilitar em toda a frota e registre a medição junto com o rollout.
• Faça o link da janela de tempo de um alerta de latência para o perfil da mesma janela.

Armadilhas

Endpoints de profiling expostos publicamente vazam a estrutura do código e permitem que qualquer pessoa dispare uma coleta de perfil custosa. Binários stripped ou a falta de frame pointers geram stacks sem nomes. Profilers de amostragem sub-representam processos de vida curta e eventos raros isolados; eles mostram para onde o tempo vai em média, não por que uma requisição específica foi lenta, o que é uma pergunta para tracing.