Extraindo telemetria avançada de SSDs NVMe via CLI: o guia definitivo

Você já passou por isso: o servidor trava, a latência de I/O dispara, o kernel cospe erros de timeout, mas quando você roda um smartctl -a, o disco sorri para você e diz: "PASSED".

O SMART é útil, mas é um resumo sanitizado. É o painel do carro dizendo que o motor está ligado. Quando o motor explode, você precisa da caixa-preta. No mundo NVMe, essa caixa-preta é o Log de Telemetria.

Diferente dos atributos SMART, que são apenas contadores, a telemetria é um dump cru do estado interno do controlador, buffers de memória e registradores no momento exato de uma falha ou sob demanda. Vamos descer ao nível do byte e aprender a extrair esses dados usando nvme-cli.

Resumo em 30 segundos

SMART vs. Telemetry: O SMART mostra sintomas (contadores de erro); a Telemetria mostra a causa raiz (dump de memória do controlador e registradores).

Ferramenta: Usaremos o nvme-cli para acessar as Log Pages 0x07 (Host-Initiated) e 0x08 (Controller-Initiated).

O Arquivo: O resultado é um binário proprietário. Você consegue ler o cabeçalho, mas o payload (Data Areas) geralmente só é decifrável pelo fabricante do SSD.

Por que o SMART mente (ou omite)

O SMART (Self-Monitoring, Analysis, and Reporting Technology) foi projetado na era dos HDDs para prever falhas mecânicas. Em SSDs NVMe, ele foi adaptado, mas continua sendo um conjunto de contadores cumulativos.

Se o firmware do seu SSD entra em um loop de coleta de lixo (Garbage Collection) ou encontra uma race condition na DRAM interna, o SMART não vai registrar isso como um "erro de mídia". Ele simplesmente não sabe como categorizar.

A Telemetria NVMe (introduzida na especificação NVMe 1.3) resolve isso permitindo que o host (você) ou o próprio controlador capturem um instantâneo do estado interno. É o equivalente a um kernel core dump, mas dentro do SSD.

Figura: Comparativo visual: O SMART oferece métricas superficiais, enquanto a Telemetria extrai o estado interno profundo do controlador e buffers de memória.

Preparando o Arsenal: `nvme-cli`

Para interagir com os registradores do dispositivo, precisamos do canivete suíço do armazenamento no Linux: nvme-cli.

⚠️ Perigo: A extração de telemetria não é uma operação passiva. Dependendo da implementação do firmware, o controlador pode pausar todo o I/O para despejar o conteúdo da sua RAM interna para a área de buffer de telemetria. Nunca execute isso em um disco de produção sob carga máxima sem janelas de manutenção.

Verificando versões e suporte

A sintaxe mudou ligeiramente entre as versões 1.x e 2.x do nvme-cli. Este guia foca na sintaxe moderna (2.x), mas os conceitos são universais.

Primeiro, verifique se o seu dispositivo suporta telemetria. Nem todo NVMe implementa isso (especialmente modelos consumer baratos).

nvme id-ctrl /dev/nvme0 -H | grep -i "telemetry"

Se você vir algo como Telemetry Log Supported, estamos no jogo. Se o retorno for vazio, o controlador não implementa a especificação de Log Page de telemetria padrão (TP 4002).

A Anatomia dos Logs: 0x07 vs 0x08

A especificação NVMe define duas páginas de log cruciais para telemetria. Entender a diferença é vital para saber o que você está caçando.

Tabela Comparativa: Tipos de Telemetria

Característica	Host-Initiated (Log 0x07)	Controller-Initiated (Log 0x08)
Gatilho	Manual (Admin roda o comando).	Automático (Firmware detecta erro grave).
Objetivo	Debug de performance, análise de estado atual.	Análise post-mortem após falha/panic.
Volatilidade	Dados gerados no momento do comando.	Dados persistem após power cycle (geralmente).
Bit "Create"	O Host deve setar o bit para gerar o dump.	O Host apenas lê o que já está salvo.

💡 Dica Pro: Se o seu SSD "sumiu" do sistema e reapareceu após um reboot, verifique imediatamente o Log 0x08. É provável que o controlador tenha salvo o motivo do crash lá.

Executando a Extração (Host-Initiated)

Vamos supor que você queira investigar um problema de latência atual. Vamos forçar o controlador a gerar um relatório de telemetria.

O comando básico é nvme telemetry-log.

1. Gerando e capturando o relatório

Para extrair a telemetria iniciada pelo host (Log 0x07), precisamos dizer ao controlador para "criar" (gerar) os dados agora.

# Sintaxe para nvme-cli 2.x
sudo nvme telemetry-log /dev/nvme0 --output-file=telemetry_dump.bin --host-generate

Dissecando as flags:

/dev/nvme0: O dispositivo alvo (use o character device, não o block device nvme0n1, embora ambos funcionem na maioria das vezes, falar com o controlador é mais purista).
--output-file (ou -o): Onde o binário será salvo. Se omitido, ele cospe lixo binário no seu stdout (não faça isso).
--host-generate (ou -g): Crítico. Isso seta o bit "Create" no comando. Sem isso, você pode estar lendo um buffer antigo ou vazio.

2. Extraindo telemetria persistente (Controller-Initiated)

Se você está investigando um evento passado (Log 0x08), não use a flag de geração. Você quer ler o que já está lá.

sudo nvme telemetry-log /dev/nvme0 --output-file=crash_dump.bin --log-id=8

Aqui especificamos --log-id=8 explicitamente para buscar a telemetria iniciada pelo controlador.

O que fazer com o arquivo `.bin`?

Você agora tem um arquivo de 512KB a alguns Megabytes. Se você tentar ler com cat, vai quebrar seu terminal.

A estrutura do Log de Telemetria é definida pela especificação NVMe, mas o conteúdo profundo é proprietário.

A Estrutura do Arquivo

O arquivo é dividido em blocos:

Header (512 bytes): Padronizado pela NVMe Spec. Contém identificadores, status da geração e tamanhos das áreas de dados.
Data Area 1: Dados críticos e pequenos.
Data Area 2: Dados estendidos.
Data Area 3: Dados volumosos (dumps de RAM completos).

Figura: Estrutura do arquivo de log: O cabeçalho é padronizado e legível, mas as Áreas de Dados 1, 2 e 3 contêm informações proprietárias do fabricante.

Lendo o Cabeçalho

Embora não possamos decifrar os dados proprietários da Samsung ou Intel sem as ferramentas internas deles, podemos validar o cabeçalho para garantir que a captura funcionou.

O próprio nvme-cli pode fazer o parse do cabeçalho para nós se não usarmos a flag de saída binária, ou podemos usar ferramentas como od ou hexdump para inspecionar o início do arquivo binário.

Para ver o cabeçalho legível no terminal:

sudo nvme telemetry-log /dev/nvme0 --host-generate

(Sem o -o, ele formata o cabeçalho em texto legível e ignora o payload binário na saída padrão).

Você verá campos como:

Telemetry Controller-Initiated Data Available: yes/no
Reason Identifier: Um código que diz por que o log foi gerado.

Troubleshooting: Erros Comuns

"Invalid Field in Command"

Você rodou o comando e recebeu este erro genérico.

Suporte: O drive realmente suporta Log Page 0x07/0x08? (Verifique id-ctrl).
Tamanho do Buffer: Alguns controladores exigem que o host aloque o buffer de tamanho exato antes de pedir o log. Tente adicionar --data-area flags se souber os tamanhos específicos (raro ser necessário em versões novas do CLI).
Namespace vs Controller: Tente apontar para /dev/nvme0 em vez de /dev/nvme0n1.

O arquivo gerado está cheio de zeros

Se o arquivo tem tamanho, mas o conteúdo é zero:

Verifique se o bit Data Available no cabeçalho está setado.
Se for Host-Initiated, você esqueceu o --host-generate? Se você apenas ler o log 0x07 sem pedir para gerar, o controlador pode retornar o buffer antigo ou vazio.

O Futuro da Telemetria: OCP e Padronização

A indústria de armazenamento está se movendo para tornar esses dados menos "caixa-preta". A especificação OCP Datacenter NVMe SSD está forçando fabricantes a padronizar certos campos dentro da telemetria, permitindo que hyperscalers (e nós, meros mortais) possamos decodificar métricas de saúde sem enviar o SSD de volta para a fábrica.

Até lá, saber extrair esses logs é a diferença entre dizer "o disco falhou" e dizer "o disco falhou e aqui está o dump de memória para o engenheiro de firmware analisar". É assim que você eleva o nível do seu diagnóstico de infraestrutura.

FAQ

Eu consigo ler o conteúdo do arquivo de telemetria?

Geralmente não. A maior parte dos dados de telemetria (Data Area 1, 2 e 3) é proprietária e codificada pelo fabricante (Vendor Specific). O objetivo é enviar esse 'dump' para a engenharia da marca (Intel, Samsung, Micron) analisar falhas de firmware.

A extração de telemetria impacta a performance do disco?

Sim. A telemetria iniciada pelo host (Host-Initiated) pode pausar momentaneamente o processamento de comandos de I/O para coletar o estado interno dos registradores e buffers do controlador.

Qual a diferença entre 'Host-Initiated' e 'Controller-Initiated'?

Host-Initiated é quando você (admin) solicita o log voluntariamente (ex: para debug). Controller-Initiated é gerado automaticamente pelo SSD quando ele detecta um erro interno grave ou pânico, salvando o estado para análise posterior.