Análise de latência de storage com eBPF: vendo o invisível no iostat

Você recebe um alerta de lentidão no banco de dados. O tempo de resposta da aplicação subiu para 500ms. Você acessa o servidor, roda o iostat -x 1 e vê o await (latência média) em confortáveis 2ms. O disco parece ocioso. Você culpa a rede, a aplicação, o DNS. Mas o problema está no disco.

O iostat mentiu para você? Não exatamente. Ele apenas lhe deu a média aritmética. E em armazenamento de alta performance, a média é o lugar onde os problemas se escondem.

Resumo em 30 segundos

O problema: O iostat exibe médias de latência. Uma média de 2ms pode esconder requisições individuais de 200ms que travam transações críticas (latência de cauda).

A solução: Ferramentas baseadas em eBPF (biolatency, biosnoop) capturam cada operação de I/O individualmente no kernel, gerando histogramas precisos.

O resultado: Você consegue visualizar a distribuição real da latência (P99, P99.9) e identificar exatamente qual processo está causando o gargalo, sem derrubar a performance do servidor.

A tirania das médias no armazenamento

Imagine que você tem 100 requisições de I/O.

99 delas levam 0.1ms (cache hit ou NVMe rápido).
1 delas leva 100ms (uma leitura aleatória em HDD ou garbage collection de SSD).

A média (await) será aproximadamente 1.1ms. Olhando para o iostat, o disco está voando. Mas para o usuário que caiu naquela 1 requisição de 100ms, o sistema travou. Em escala de datacenter, com milhares de IOPS (Input/Output Operations Per Second), esses "outliers" se acumulam e causam o que chamamos de latência de cauda (tail latency).

É aqui que o modelo de observabilidade tradicional falha. Precisamos de histogramas, não de médias.

Figura: Comparação visual: como a média do iostat suaviza o problema versus a realidade mostrada por um histograma de latência.

Entra em cena o eBPF e o BCC

O eBPF (Extended Berkeley Packet Filter) é uma tecnologia revolucionária no kernel Linux que permite rodar programas "sandboxed" dentro do kernel sem precisar recompilá-lo ou carregar módulos arriscados.

Para análise de disco, isso significa que podemos instrumentar as chamadas de bloco (block device layer) com custo de performance quase zero. Diferente do strace, que pausa a aplicação a cada chamada de sistema (context switch hell), o eBPF coleta os dados e envia apenas o resumo para o espaço do usuário.

Para usar as ferramentas que vamos discutir, você precisa do pacote bcc-tools (BPF Compiler Collection).

Instalação rápida:

# Ubuntu/Debian
sudo apt-get install bpfcc-tools linux-headers-$(uname -r)

# RHEL/CentOS/Fedora
sudo yum install bcc-tools

Nota: As ferramentas geralmente ficam em /usr/sbin/ ou /usr/share/bcc/tools/ e podem ter a extensão .py ou não, dependendo da distro.

biolatency: O mapa de calor do seu disco

O comando biolatency rastreia o tempo de início e fim de cada requisição de bloco (BIO) e monta um histograma em tempo real.

Vamos rodar o comando para analisar o disco por alguns segundos:

# Rastreia latência de I/O de disco e exibe em microssegundos (-m)
sudo biolatency -m

Saída típica:

Tracing block device I/O... Hit Ctrl-C to end.
^C
     usecs               : count     distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 0        |                                        |
         4 -> 7          : 0        |                                        |
         8 -> 15         : 0        |                                        |
        16 -> 31         : 12       |                                        |
        32 -> 63         : 85       |**                                      |
        64 -> 127        : 1542     |****************************************|
       128 -> 255        : 840      |*********************                   |
       256 -> 511        : 24       |                                        |
       512 -> 1023       : 2        |                                        |
      1024 -> 2047       : 0        |                                        |
      2048 -> 4095       : 1        |                                        |

Interpretando o histograma

Olhe para a coluna usecs (microssegundos).

A maior parte das operações (1542 contagens) ocorreu entre 64 e 127 microssegundos. Isso é excelente, típico de um SSD NVMe Enterprise.
Mas veja o final: temos 1 operação entre 2048 e 4095 usecs (2ms a 4ms).

Se o seu iostat mostrasse média de 0.1ms, ele estaria tecnicamente correto, mas esconderia aquele pico de 4ms. Em um cenário de problema real, você veria barras surgindo na casa dos 100.000 usecs (100ms) ou mais, provando a lentidão que a média esconde.

💡 Dica Pro: Use a flag -D para ver histogramas separados por disco físico. Útil se você tem um array misto de SSDs e HDDs e quer saber qual drive específico está engasgando.

biosnoop: Identificando o processo culpado

O biolatency diz como a latência está distribuída, mas não diz quem está causando ou sofrendo com ela. Para isso, usamos o biosnoop. Ele imprime uma linha para cada operação de I/O completada.

sudo biosnoop

Saída:

TIME(s)     COMM           PID    DISK    T  SECTOR     BYTES   LAT(ms)
0.000000    kworker/u4:1   182    nvme0n1 W  24536064   4096    0.06
0.000342    mysqld         921    nvme0n1 R  10544200   16384   12.50
0.000410    jbd2/nvme0n1   345    nvme0n1 W  442910     4096    0.08

Aqui pegamos o culpado no flagra.

O processo mysqld (PID 921) fez uma leitura (R) no disco nvme0n1.
A latência (LAT) foi de 12.50ms.
Enquanto isso, o kworker e o jbd2 (journal do ext4) tiveram latências sub-milissegundo.

Isso isola o problema: não é o disco inteiro que está lento, é aquela operação específica do MySQL. Pode ser uma leitura de um bloco danificado, contenção de fila ou fragmentação.

A flag crítica: -Q (Queue Time)

A latência total do disco é composta por:

Tempo de Fila (Queue): Tempo esperando no scheduler do OS.
Tempo de Serviço (Service): Tempo que o hardware leva para buscar o dado.

Se você usar biosnoop -Q, ele separa essas métricas.

⚠️ Perigo: Se o "Queue Time" for alto e o "Service Time" for baixo, o problema não é o disco, é o kernel/scheduler ou limite de IOPS configurado (cgroups/throttling). Se o "Service Time" for alto, o hardware do disco está sobrecarregado ou falhando.

Figura: Diagrama técnico do caminho de I/O no Linux, diferenciando Tempo de Fila (Queue) e Tempo de Serviço (Hardware), métricas essenciais do biosnoop.

Simulando o caos com fio

Não acredite apenas na teoria. Vamos validar essas ferramentas gerando um gargalo artificial. Usaremos o fio (Flexible I/O Tester), a ferramenta padrão da indústria para benchmark de storage.

Crie um arquivo de job teste_latencia.fio:

[global]
ioengine=libaio
direct=1
bs=4k
size=1G
time_based
runtime=30

[leitura-aleatoria-lenta]
rw=randread
iodepth=128
numjobs=4
filename=fio_test_file

Ao rodar fio teste_latencia.fio, estamos bombardeando o disco com leituras aleatórias e uma profundidade de fila (iodepth) alta.

Enquanto o fio roda:

Abra outro terminal.
Execute iostat -x 1. Você verá o await subir, mas talvez se mantenha estável.
Execute biolatency -m. Você verá o histograma se deslocar para a direita, acumulando valores nas faixas de latência mais alta.
Execute biosnoop. Você verá o processo fio dominando a saída com latências altas.

Essa validação é crucial para entender a "assinatura visual" de um disco saturado antes que aconteça em produção.

Tabela Comparativa: Escolhendo a arma certa

Característica	iostat	biolatency (eBPF)	biosnoop (eBPF)
Métrica Principal	Médias (await, svctm)	Histograma (distribuição)	Eventos individuais (trace)
Overhead	Quase nulo	Muito baixo	Baixo/Médio (depende do volume de I/O)
Visibilidade	Visão macro do sistema	Visão de comportamento (P99)	Visão forense (quem e onde)
Uso Ideal	Monitoramento contínuo (Dashboards)	Diagnóstico de lentidão intermitente	Debugging de processos específicos
Requisito	Padrão em qualquer Linux	Kernel 4.1+ & BCC Tools	Kernel 4.1+ & BCC Tools

Quando o eBPF falha (Troubleshooting)

Nem tudo são flores. Você pode tentar rodar essas ferramentas e receber erros crípticos.

Erro de Kernel Headers: O BCC precisa compilar o código BPF "on-the-fly". Se os headers do kernel atual não estiverem instalados, ele falha. Garanta que o pacote linux-headers-$(uname -r) esteja presente.
Lockdown Mode: Em servidores com Secure Boot ativado, o kernel pode entrar em modo "Lockdown", impedindo o uso de kprobes (que o BCC usa para inspecionar o kernel). Se vir erros de "Operation not permitted" mesmo como root, verifique o Secure Boot na BIOS/UEFI.
Versão do Kernel: Embora o eBPF exista há tempos, recursos avançados de trace de bloco exigem kernels 4.1 ou superiores. A maioria das distros Enterprise (RHEL 8+, Ubuntu 20.04+) já atende a isso, mas sistemas legados (CentOS 7 com kernel 3.10) não rodarão essas ferramentas nativamente.

O fim da era da adivinhação

Continuar diagnosticando performance de storage apenas com iostat em 2025 é como tentar pilotar um avião olhando apenas para o altímetro médio da viagem. Você sabe que chegou, mas não sabe se quase bateu numa montanha no caminho.

A latência de cauda é onde os SLAs são violados. Ferramentas como biolatency e biosnoop não são apenas "bonitas de se ver"; elas são obrigatórias para qualquer engenheiro que gerencia bancos de dados, virtualização ou storage de alta densidade. Instale o bcc-tools na sua imagem base hoje, não espere o incidente acontecer para descobrir que você não tem visibilidade.

Perguntas Frequentes (FAQ)

Qual a diferença entre usar iostat e ferramentas eBPF para disco?

O iostat fornece médias de latência que suavizam picos e escondem problemas intermitentes. Ferramentas eBPF como biolatency criam histogramas detalhados, permitindo visualizar a latência de cauda (P99/P99.9) onde ocorrem os timeouts reais que afetam a aplicação.

O uso de eBPF causa impacto na performance do servidor de storage?

O impacto é extremamente baixo e seguro para ambientes de produção. O eBPF executa bytecode verificado dentro do kernel, evitando o overhead massivo de trocas de contexto (context switches) que ferramentas de trace antigas, como o strace, causavam.

O que é latência de cauda em armazenamento?

Refere-se aos "outliers" de performance, geralmente o 1% das requisições mais lentas (P99). Em storage, uma média de 1ms pode parecer ótima, mas esconder requisições ocasionais de 500ms que travam o banco de dados ou causam timeout na aplicação.