A mentira das médias: como o eBPF revela a verdadeira latência de cauda no storage

O banco de dados engasga, as requisições dos usuários expiram por timeout e a equipe de suporte entra em pânico. Você abre o painel de monitoramento da infraestrutura e olha para o gráfico de latência do disco. A linha está perfeitamente plana, reportando confortáveis dois milissegundos de tempo de resposta. O painel diz que está tudo bem, mas o sistema está pegando fogo.

Você está sendo enganado pela matemática básica.

Na engenharia de performance de storage, depender de médias para entender o comportamento de discos modernos é o equivalente a dirigir vendado. Quando lidamos com matrizes de armazenamento flash de alta performance e protocolos desenhados para microssegundos, a média esconde os exatos eventos que destroem a experiência do usuário. Para ver o invisível e entender a verdadeira latência de cauda, precisamos abandonar os contadores agregados e mergulhar no kernel do sistema operacional.

Resumo em 30 segundos

Ferramentas tradicionais como o iostat calculam médias baseadas em janelas de tempo, mascarando picos de latência severos em discos rápidos.

Aumentar a frequência de coleta de métricas não resolve o problema, apenas gera mais ruído no monitoramento.

O eBPF permite instrumentar o kernel de forma segura para capturar cada evento de I/O, revelando a latência de cauda real através de histogramas de alta cardinalidade.

A ilusão do iostat e o perigo de agregar métricas de bloco

A maioria das ferramentas de monitoramento de infraestrutura que usamos hoje tem suas raízes em décadas passadas. O venerável iostat, por exemplo, é a ferramenta padrão para análise de discos no Linux. Ele funciona lendo os contadores expostos pelo kernel no arquivo /proc/diskstats. O problema fundamental não é a ferramenta em si, mas a forma como ela processa os dados.

O iostat calcula a diferença entre os contadores de operações concluídas e o tempo gasto nelas durante um intervalo específico, geralmente de um segundo. A partir daí, ele divide um valor pelo outro para entregar a latência média.

Se o seu disco processa dez mil operações em um segundo, e 9.999 delas levam 100 microssegundos, mas uma única operação fica travada na controladora por cruéis 200 milissegundos, a média matemática vai diluir esse desastre. O painel mostrará uma latência perfeitamente aceitável. No entanto, aquela única operação lenta (o outlier) pode ser exatamente a gravação do log de transação que travou toda a fila do seu banco de dados relacional.

Figura: Gráfico conceitual mostrando como a linha de média esconde os picos extremos de latência de cauda.

Aumentar a frequência de coleta apenas gera ruído

A reação instintiva de muitos engenheiros ao descobrir que estão perdendo dados em janelas de um segundo é tentar diminuir o intervalo. Eles configuram seus agentes de telemetria para coletar dados a cada 100 milissegundos.

Essa abordagem falha por dois motivos críticos. Primeiro, ler o /proc/diskstats em alta frequência consome ciclos preciosos de CPU (overhead) sem garantir que você vai capturar o evento anômalo. Se o pico de latência durar apenas 5 milissegundos, ele ainda será engolido pela média da janela de 100 milissegundos.

Segundo, você está apenas aumentando o volume de dados inúteis no seu banco de dados de séries temporais. Você não precisa de mais médias. Você precisa de alta cardinalidade. Você precisa saber exatamente quanto tempo cada operação individual levou na camada de blocos do sistema operacional.

⚠️ Perigo: Tentar fazer "polling" (consultas repetitivas) agressivo em arquivos do sistema de arquivos virtual do Linux em servidores de banco de dados de alta carga pode causar contenção de locks no kernel, piorando a performance que você está tentando medir.

Instrumentação no kernel com eBPF para capturar a realidade

É aqui que a observabilidade moderna muda o jogo. O eBPF (Extended Berkeley Packet Filter) é uma tecnologia revolucionária que permite executar programas em um ambiente isolado (sandbox) dentro do kernel do Linux, sem a necessidade de alterar o código-fonte do sistema operacional ou carregar módulos arriscados.

Para o storage, o eBPF nos permite anexar sondas (probes) diretamente nos pontos de rastreamento (tracepoints) da camada de blocos, como block_rq_issue (quando a requisição é enviada ao disco) e block_rq_complete (quando o disco responde).

Em vez de calcular médias, um programa eBPF mede o tempo exato de cada requisição individual. Para evitar o custo de enviar milhões de eventos por segundo para o espaço de usuário, o eBPF agrega esses dados dentro do próprio kernel usando estruturas de dados altamente eficientes chamadas mapas (BPF maps). O resultado é um histograma perfeito da latência, gerado com impacto quase zero na performance do servidor.

Comparativo de ferramentas de análise de storage

Para entender a mudança de paradigma, precisamos comparar a abordagem legada com a instrumentação moderna baseada em eventos reais.

Característica	iostat (Abordagem Legada)	biolatency / eBPF (Abordagem Moderna)
Mecanismo	Leitura de contadores agregados (`/proc/diskstats`).	Rastreamento de eventos individuais no kernel.
Granularidade	Médias por segundo (ou intervalo definido).	Microssegundos ou nanossegundos por operação.
Visibilidade de Outliers	Cega. Dilui picos extremos na média matemática.	Total. Exibe a latência de cauda (P99, P99.9) em histogramas.
Impacto (Overhead)	Baixo, mas aumenta se a frequência de coleta subir.	Extremamente baixo, agregação feita no próprio kernel.
Melhor Caso de Uso	Visão geral de throughput e IOPS a longo prazo.	Troubleshooting de engasgos, micro-bursts e anomalias de I/O.

Comparando o P99 do eBPF contra a média em discos NVMe

A diferença entre essas duas abordagens se torna gritante quando lidamos com hardware moderno. O protocolo NVMe (Non-Volatile Memory Express) foi criado para conectar o armazenamento flash diretamente ao barramento PCIe do servidor. Estamos falando de dispositivos capazes de entregar milhões de IOPS com latências na casa dos dezenas de microssegundos.

Em um cenário real de pico de gravação (micro-burst), o buffer interno do SSD NVMe pode encher. Quando isso acontece, o disco precisa realizar a coleta de lixo (garbage collection) nas células de memória NAND antes de aceitar novas gravações. Durante esse processo, algumas requisições de I/O podem demorar 50 ou 100 milissegundos.

Se você olhar para o iostat durante esse evento, verá uma latência média de 0.5 milissegundos. Tudo parece normal. Mas se você rodar a ferramenta biolatency (parte do pacote BCC do eBPF), o histograma revelará a verdade nua e crua. Você verá uma montanha de requisições rápidas e, no final do gráfico, uma cauda longa e isolada mostrando requisições travadas na barreira dos milissegundos. Esse é o seu P99 (o percentil 99). É essa cauda que está causando o timeout na sua aplicação.

Figura: Comparação visual entre a saída plana do iostat e o histograma bimodal gerado pelo biolatency via eBPF.

💡 Dica Pro: Ao analisar latência de storage, pare de olhar para a média (P50). Concentre seus alertas no P95 e no P99. Se o seu P99 de disco estiver alto, uma porcentagem significativa das transações dos seus usuários está sofrendo, mesmo que o volume total de IOPS pareça saudável.

O fim do achismo na engenharia de performance

A observabilidade não é apenas sobre coletar mais dados. É sobre coletar os dados certos que permitem fazer perguntas que você não sabia que precisava fazer. Quando você tem a capacidade de rastrear o I/O bloco a bloco, você para de adivinhar se o problema está na rede, no hypervisor ou no disco físico.

Com ferramentas baseadas em eBPF como o biosnoop, você pode ver exatamente qual processo (PID) emitiu a requisição de bloco que sofreu a latência extrema. Você pode correlacionar um engasgo no disco diretamente com a query específica do PostgreSQL que causou o problema. Isso é o fim do achismo.

Figura: Arquitetura da pilha de storage do Linux mostrando onde o eBPF se conecta para extrair métricas de alta fidelidade.

O hardware de armazenamento evoluiu de forma exponencial na última década. Passamos de discos magnéticos giratórios para memórias flash conectadas via PCIe. No entanto, muitos de nós ainda tentam diagnosticar problemas de performance usando as mesmas métricas agregadas dos anos 1990.

A latência de cauda é onde os problemas reais de produção vivem. Ela é o assassino silencioso da confiabilidade dos sistemas distribuídos. Continuar confiando em médias para monitorar discos NVMe de alta performance não é apenas uma limitação técnica, é uma negligência operacional. Adote a instrumentação no nível do kernel, abrace os histogramas e comece a exigir a verdade absoluta da sua infraestrutura de storage.

Referências & Leitura Complementar

BPF Performance Tools (Brendan Gregg, Addison-Wesley Professional). O guia definitivo sobre o uso de eBPF para análise de performance de sistemas e storage.
NVM Express Base Specification (NVM Express, Inc.). Documentação oficial sobre o funcionamento das filas de submissão e completude do protocolo NVMe.
Linux Kernel Documentation: BPF (kernel.org). Documentação técnica sobre a implementação de mapas BPF e tracepoints na camada de blocos.

Por que o iostat não mostra a latência máxima real do disco?

O iostat calcula médias com base em contadores do kernel (/proc/diskstats) em intervalos de tempo. Se um disco NVMe tiver 999 operações em microssegundos e 1 operação travada por 50 milissegundos no mesmo segundo, a média matemática esconderá a operação lenta, mascarando completamente a latência de cauda que afeta o usuário.

O eBPF adiciona overhead no servidor de storage em produção?

O overhead do eBPF é extremamente baixo e seguro para produção. Ele compila o código JIT (Just-In-Time) e executa de forma isolada no kernel, agregando dados em mapas eficientes (como histogramas) antes de enviá-los ao espaço de usuário, evitando o custo de cópia de dados de ferramentas antigas de tracing.

Quais ferramentas eBPF substituem o iostat para análise de discos?

Ferramentas do pacote bcc (BPF Compiler Collection), como o 'biolatency' (que gera histogramas de latência em milissegundos ou microssegundos) e o 'biosnoop' (para rastrear I/O bloco a bloco por processo), são os padrões modernos da indústria para obter a visão de alta cardinalidade que o iostat não consegue fornecer.