Muito além do SMART: decodificando a telemetria de SSDs NVMe para prever degradação de performance

Você já passou por isso: o dashboard do Grafana fica vermelho, a latência p99 do seu banco de dados distribuído salta de 2ms para 400ms e o time de aplicação jura que o código não mudou. Você corre para o servidor, roda um smartctl -H /dev/nvme0n1 e recebe um insultante "PASSED". O disco diz que está saudável, mas sua infraestrutura está sangrando.

O problema é que tratamos SSDs como caixas pretas binárias: ou funcionam ou falham. Na era da observabilidade moderna, isso é inaceitável. Discos NVMe são computadores complexos rodando firmwares multicore, gerenciando filas, bufferização e realocação de blocos em tempo real. Olhar apenas para o SMART é como tentar diagnosticar uma arritmia cardíaca medindo apenas a temperatura do paciente.

Para entender a degradação de performance antes que ela vire um incidente, precisamos descer o nível. Precisamos falar de telemetria bruta.

Resumo em 30 segundos

SMART é legado: Projetado para prever falhas catastróficas de hardware, ele é cego para problemas transientes de performance, como saturação de cache ou throttling térmico leve.

A verdade está nos Logs: A especificação NVMe moderna oferece "Telemetry Log Pages" (0x07 e 0x08) que expõem o estado interno do controlador, filas e eventos de garbage collection.

Correlação é rei: A única forma de provar que o disco é o culpado pela latência da aplicação é cruzar os timestamps dos eventos de firmware com os traces da sua aplicação.

O mito do status "OK" e a cegueira do SMART

O SMART (Self-Monitoring, Analysis, and Reporting Technology) nasceu na era dos discos rotativos (HDD). Ele é excelente para dizer se o motor do disco está parando ou se há setores defeituosos físicos. Em um SSD NVMe, atributos como Critical Warning ou Percentage Used são úteis para planejamento de capacidade a longo prazo, mas inúteis para depuração de performance em tempo real.

Um SSD pode estar com 100% de saúde e ainda assim entregar uma performance terrível. Isso acontece porque o SMART não monitora "esforço", ele monitora "dano". Se o controlador do SSD está gastando 90% dos seus ciclos de CPU reorganizando blocos de memória (Garbage Collection) porque você encheu o disco, o SMART dirá que está tudo bem. Enquanto isso, suas gravações estão em uma fila de espera, criando o que chamamos de "latência de cauda" (tail latency).

💡 Dica Pro: Pare de configurar alertas apenas para Media Errors. Configure alertas para Available Spare caindo abaixo do limiar e, mais importante, monitore a latência de I/O diretamente via eBPF ou métricas do exportador do nó, correlacionando com os dados que vamos extrair abaixo.

A anatomia de um engasgo: cache SLC e garbage collection

Para entender o que buscar na telemetria, você precisa visualizar o que acontece dentro do NAND. A maioria dos SSDs modernos (TLC ou QLC) usa uma porção da memória como cache SLC (Single Level Cell). Gravar aqui é rápido (1 bit por célula). Quando esse cache enche, o disco entra em modo de "folding", movendo dados para a área TLC/QLC (lenta).

Se sua aplicação continua bombardeando o disco com gravações durante esse processo, a performance cai de um penhasco. O controlador NVMe precisa pausar o I/O do host para limpar a casa.

Figura: Visualização do "Write Cliff": o momento exato em que o cache SLC satura e a latência dispara.

O SMART não registra esse evento como erro. Mas os logs de telemetria registram a transição de estados do controlador e o aumento da ocupação das filas de submissão.

Extraindo a verdade com nvme-cli

A ferramenta padrão da indústria para interagir com o subsistema de armazenamento no Linux é o nvme-cli. Esqueça ferramentas gráficas proprietárias se você quer automação e escala. A especificação NVMe 1.3 introduziu um mecanismo padronizado para extração de telemetria.

Existem dois tipos principais de logs de telemetria:

Host-Initiated (Log Page 0x07): O host (seu servidor) pede ao disco para capturar seu estado atual. Útil quando você detecta uma anomalia e quer um "snapshot" do agora.
Controller-Initiated (Log Page 0x08): O próprio disco decide salvar um log porque algo crítico aconteceu (pânico do firmware, erro interno grave).

Para extrair esses dados, usamos:

nvme id-ctrl /dev/nvme0n1 | grep -i telemetry

# Criar um log iniciado pelo host (snapshot do estado atual)
sudo nvme telemetry-log /dev/nvme0n1 --output-file=nvme_telemetry_dump.bin --host-generate

O arquivo gerado (.bin) é um blob binário. A má notícia? A especificação NVMe define o cabeçalho desse log, mas o payload (o conteúdo real) é específico de cada fabricante (Vendor Specific). A boa notícia? Fabricantes Enterprise (Solidigm, Samsung, Micron, Kioxia) fornecem ferramentas ou plugins para decodificar esses binários, e a comunidade Open Source tem avançado na engenharia reversa desses padrões.

Decodificando o que importa

Mesmo sem o decodificador proprietário completo, o cabeçalho da telemetria (primeiros 512 bytes) nos dá pistas vitais que o SMART esconde:

Reason Identifier: Por que o log foi gerado?
Controller Status: O firmware estava em estado de exceção?

Para uma análise granular sem depender de blobs binários opacos, devemos olhar para os NVMe Error Log Pages estendidos e Smart Log Pages estendidos (Log Page 0x02).

⚠️ Perigo: Rodar comandos de administração NVMe (como resets ou atualizações de firmware) em um disco montado e em uso pode causar corrupção de dados ou travamento do kernel. A extração de logs (telemetry-log ou smart-log) é segura, mas deve ser feita com ferramentas atualizadas.

Correlacionando firmware com a camada de aplicação

Aqui é onde a mágica da observabilidade acontece. Não adianta ter o log do SSD se ele não estiver contextualizado. O objetivo é responder: "A lentidão das 14:03 foi causada pelo disco?"

Você precisa cruzar três vetores de dados:

Métricas do SO (eBPF/iostat): Latência de fila, tamanho da fila, IOPS.
Eventos do Firmware (NVMe Logs): Início de Garbage Collection, Thermal Throttling, Reallocated Sector Events.
Traces da Aplicação: Spans de transações lentas.

Se o seu trace mostra um db.query demorando 2 segundos, e no mesmo milissegundo o nvme-cli reporta um pico na temperatura composta (Composite Temperature) seguido de um evento de Critical Warning: Temperature Threshold, você tem sua causa raiz: Thermal Throttling. O disco reduziu o clock para não derreter, matando sua performance. O SMART só mostraria que a temperatura máxima foi atingida em algum momento do passado, mas a telemetria temporal te dá o "quando".

Figura: A pilha completa de observabilidade de armazenamento: conectando o código ao silício.

Tabela Comparativa: SMART vs. Telemetria Avançada

Característica	SMART Padrão	Telemetria NVMe / Logs Estendidos
Foco	Previsão de Falha de Hardware	Análise de Comportamento e Debug
Granularidade	Contadores cumulativos (desde o boot)	Snapshots de estado e buffers circulares
Visibilidade de Cache	Nenhuma	Visível via logs de vendor ou latência de gravação
Eventos Térmicos	Apenas temperatura atual/máxima	Histórico de throttling e gestão de energia
Complexidade	Baixa (leitura direta)	Alta (requer parsing e correlação)

O futuro da visibilidade: OCP e ZNS

A indústria sabe que os blobs binários proprietários são um pesadelo para a engenharia de confiabilidade (SRE). Por isso, grandes players (Meta, Microsoft, Google) através do Open Compute Project (OCP) criaram a especificação OCP Datacenter NVMe SSD.

Esta especificação obriga os fabricantes a exporem métricas de telemetria em formato legível e padronizado (Log Page 0xC0), incluindo:

Contadores de latência física (não apenas lógica).
Contadores de erro de bit (BER) detalhados.
Status detalhado do buffer de recuperação.

Além disso, tecnologias como ZNS (Zoned Namespaces) estão mudando o jogo. No ZNS, o host (software) decide onde os dados são gravados fisicamente, eliminando a necessidade do SSD fazer Garbage Collection pesado internamente. Isso remove a "caixa preta" da performance. Se a latência subir no ZNS, a culpa é do seu software de gerenciamento de zonas, não de um firmware misterioso.

Figura: ZNS (Zoned Namespaces): Eliminando o ruído do vizinho barulhento ao passar o controle da alocação física para o host.

O fim da engenharia baseada em esperança

Monitorar armazenamento apenas verificando se a luz está verde é engenharia baseada em esperança. Discos NVMe são sistemas dinâmicos e vivos. A degradação de performance é quase sempre um precursor de falha ou, no mínimo, um assassino de experiência do usuário.

Ao adotar a coleta de logs de telemetria e correlacioná-los com suas métricas de aplicação, você deixa de ser um espectador passivo de incidentes de I/O e passa a ser um investigador ativo. Não espere o disco morrer. Escute o que ele está sussurrando enquanto trabalha.

Referências & Leitura Complementar

NVM Express Base Specification 2.0: Seção sobre Telemetry Log Pages (0x07/0x08).
OCP Datacenter NVMe® SSD Specification: Documentação sobre requisitos de log padronizados (Log Page 0xC0).
SNIA (Storage Networking Industry Association): Whitepapers sobre SSD Endurance e Real-world Workloads.
nvme-cli Documentation: Man pages oficiais e repositório no GitHub para comandos avançados.

Perguntas Frequentes (FAQ)

O que é a telemetria NVMe e como ela difere do SMART?

Enquanto o SMART foca na saúde física e previsão de falha catastrófica (como um check-up anual), a telemetria NVMe (Log Pages 0x07 e 0x08) oferece dados granulares sobre o comportamento interno do firmware, latência e performance momentânea, funcionando como um monitoramento em tempo real.

Como identificar se meu SSD está sofrendo de thermal throttling sem olhar o SMART?

Através da análise de histogramas de latência e logs de eventos assíncronos do controlador NVMe, é possível ver picos de latência que coincidem com reduções de clock (throttling), mesmo antes do alerta crítico de temperatura ser disparado no SMART.

Qual ferramenta usar para extrair logs de telemetria no Linux?

A ferramenta padrão da indústria é o nvme-cli. Comandos como nvme telemetry-log permitem extrair dados brutos que podem ser analisados por ferramentas do fabricante ou parsers customizados, integrando-se a pipelines de observabilidade.