NVMe‑диски часто деградируют «не как SATA»: сначала растёт latency ступеньками, появляются предупреждения контроллера и записи в NVMe‑логах, а явные ошибки в файловой системе могут проявиться уже позже.

Хорошая новость — NVMe даёт богатую телеметрию: SMART/health log, error log, self‑test log, температуру, счётчики износа и ошибок.

На практике мониторинг NVMe закрывает три задачи:

• Disk health monitoring — видеть условия работы и текущий статус (температура, ресурс, циклы питания).
• Predictive failure — ловить ранние признаки деградации (рост ``media_errors``, записи в error log, корреляция с timeouts).
• Триаж инцидентов — быстро отделить проблему диска от проблем выше (ФС, RAID, питание, PCIe, драйвер, прошивка).

Ниже — практический чек‑лист и команды, которые реально помогают на серверах и виртуалках с NVMe.

Для NVMe в Linux обычно используют два инструмента:

• ``nvme-cli`` — «родной» доступ к NVMe‑логам: SMART/health, error log, self‑test log, идентификаторы контроллера/namespace.
• ``smartctl`` (smartmontools) — универсальный вывод, удобно, если у вас уже есть единый пайплайн мониторинга под SATA/SAS и NVMe.

В проде удобно держать оба: ``smartctl`` — для унификации алертов, ``nvme-cli`` — для расследований и детализации.

apt update
apt install -y nvme-cli smartmontools

dnf install -y nvme-cli smartmontools

lsblk -d -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN
nvme list

Как правило, namespace — это ``/dev/nvme0n1``, а контроллер — ``/dev/nvme0``. Важно не путать: файловая система живёт на namespace, а многие логи читаются с контроллера.

Основная команда для чтения NVMe SMART/health log:

nvme smart-log /dev/nvme0

На части систем/моделей лог доступен и по namespace:

nvme smart-log /dev/nvme0n1

Если сомневаетесь, начинайте с контроллера (``/dev/nvme0``) и проверяйте, что вывод содержит осмысленные значения.

Названия могут слегка отличаться, но смысл и набор полей обычно стандартны. Для мониторинга я бы выделил:

• ``critical_warning`` — сводный битовый флаг критических состояний. Ноль — нормально, неноль — повод разбираться сразу.
• ``temperature`` — текущая температура (перегрев даёт троттлинг и ускоряет деградацию).
• ``available_spare`` и ``available_spare_threshold`` — запас по резервным блокам и порог.
• ``percentage_used`` — оценка «израсходованного ресурса» (0–100+). Это не «процент оставшегося времени», а индикатор того, что ресурс выработан на N % по оценке контроллера.
• ``media_errors`` — один из самых важных индикаторов: неисправимые ошибки носителя/целостности.
• ``num_err_log_entries`` — количество записей в NVMe error log (важнее динамика, чем «сам факт»).
• ``power_on_hours``, ``power_cycles``, ``unsafe_shutdowns`` — «биография» диска и качество окружения (питание/сбросы).

Поле ``critical_warning`` — битовая маска. Точная расшифровка зависит от версии спецификации и реализации, но часто встречается такая логика:

• бит 0: ``available_spare`` ниже порога;
• бит 1: температура вышла за пределы (over/under temperature);
• бит 2: деградация надёжности (device reliability degraded);
• бит 3: устройство в режиме «только чтение»;
• бит 4: требуется backup / критический ресурс.

Практическое правило: ``critical_warning`` не равен нулю — это не история «понаблюдаем», а повод немедленно проверить логи, актуальность бэкапов и план замены.

Для контекста полезно собрать идентификаторы контроллера и namespace:

nvme id-ctrl /dev/nvme0
nvme id-ns /dev/nvme0n1

Если у вас уже есть мониторинг на базе smartmontools, NVMe отлично читается через ``smartctl``:

smartctl -a /dev/nvme0

Иногда полезно явно указать тип устройства:

smartctl -a -d nvme /dev/nvme0

В выводе ищите аналоги: ``Critical Warning``, ``Media and Data Integrity Errors``, ``Percentage Used``, температуру и счётчики ``Power On Hours``/``Unsafe Shutdowns``.

Чаще всего отличия — это формат представления (например, smartmontools пересчитывает data units в удобные объёмы), а также vendor‑specific поля. Для мониторинга важнее динамика и пересечение порогов, чем совпадение цифр «до последнего знака».

``media_errors`` (в smartctl обычно ``Media and Data Integrity Errors``) — счётчик неисправимых ошибок носителя/целостности. В идеале он равен нулю и остаётся нулём.

Если ``media_errors`` стал больше нуля, действуйте по плану:

1. **Зафиксируйте текущее значение** и начните смотреть динамику (рост важнее абсолютного значения).
2. **Снимите NVMe error log** и проверьте повторяемость/тип ошибок.
3. **Проверьте kernel log** на reset/timeout/AER и корреляцию по времени.
4. **Сократите риск**: проверьте бэкапы/репликацию, подготовьте миграцию данных.
5. **Планируйте замену**: растущий ``media_errors`` в проде — это практический predictive failure.

dmesg -T | grep -iE 'nvme|pcie|aer|timeout|reset|I/O error'
journalctl -k --no-pager | grep -iE 'nvme|pcie|aer|timeout|reset|I/O error'

Регулярные reset/timeout могут означать как деградацию диска, так и проблемы окружения (PCIe, питание, прошивка, температурный режим, драйвер). Поэтому всегда смотрите связку: kernel log + рост ``num_err_log_entries`` + рост ``media_errors`` + жалобы приложений на latency.

Даже когда ``critical_warning`` ещё нулевой, в error log могут появляться записи. Снимок error log:

nvme error-log /dev/nvme0

Если хотите увидеть больше записей:

nvme error-log /dev/nvme0 -e 256

На что смотреть в первую очередь:

• повторяемость одного и того же статуса/ошибки;
• связь по времени с просадками производительности и таймаутами в ядре;
• появление ошибок после обновления ядра или изменения прошивки/BIOS.

Если error log растёт, но ``media_errors`` остаётся нулём — это ещё не приговор. Но это повод проверить термальный режим, стабильность PCIe, версию прошивки и