NVMe в Linux: SMART и Health для мониторинга дисков

Зачем администратору смотреть SMART/health у NVMe

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-cli и smartctl для 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

Быстрая инвентаризация NVMe в системе

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

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

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

SMART/health через nvme-cli: база, которую стоит знать

Основная команда для чтения 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 (битовая маска)

Поле 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

SMART через smartctl: когда нужен единый подход

Если у вас уже есть мониторинг на базе 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.

Почему значения в nvme-cli и smartctl могут отличаться

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

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Ошибка носителя (media errors): что считать нормой, а что нет

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 и journalctl

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.

NVMe error log: быстрый способ понять «что именно болит»

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

nvme error-log /dev/nvme0

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

nvme error-log /dev/nvme0 -e 256

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

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

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

Self-test для NVMe: когда он полезен и как запускать

Многие NVMe поддерживают self-test. Наличие и поведение зависят от модели и платформы, поэтому проверяйте результат и влияние на производительность в тестовом окне.

Просмотр self-test log:

nvme self-test-log /dev/nvme0

Запуск короткого теста (если поддерживается):

nvme device-self-test /dev/nvme0 --self-test-code=1

Запуск расширенного теста:

nvme device-self-test /dev/nvme0 --self-test-code=2

Температура и троттлинг: скрытая причина «странных тормозов»

NVMe чувствительны к перегреву: при достижении порогов контроллер включает thermal throttling, и вы получаете всплески latency даже без явных ошибок чтения/записи.

Базовая проверка — снова SMART/health:

nvme smart-log /dev/nvme0

Если температура регулярно высокая:

• на «железе» проверьте airflow, радиатор и расположение рядом с горячими компонентами;
• оцените, не ухудшился ли обдув после обслуживания/замены комплектующих;
• в виртуальной среде зафиксируйте симптомы и планируйте миграцию нагрузки до того, как начнутся таймауты.

Практический чек-лист алертов: что мониторить постоянно

Если нужна простая схема «без переусложнения», для каждого NVMe диска обычно достаточно следующих условий:

• critical_warning != 0 — критический алерт.
• media_errors растёт — критический алерт.
• available_spare <= available_spare_threshold — критический алерт.
• percentage_used — warning на вашем пороге (часто 80–90), critical при 100+.
• Температура — warning/critical по порогам, которые соответствуют вашей модели и условиям (перегрев — всегда расследование).
• num_err_log_entries растёт — warning, далее сверяйте с kernel log и latency.

Сбор метрик одной командой (удобно для cron)

Чтобы ловить тренды, полезно хранить историю. Простейший подход — регулярный снимок SMART/health в файл/лог (раз в 5–15 минут, по ситуации):

date -Is; nvme smart-log /dev/nvme0; echo

Альтернатива через smartmontools:

date -Is; smartctl -a /dev/nvme0; echo

Дальше можно парсить конкретные строки (grep/awk) или подключить агент мониторинга, который собирает метрики структурированно. Если вы используете расписания в Linux не только для мониторинга, пригодится разбор отличий cron и systemd timers в статье cron, crontab и systemd timers: что выбрать и как не ошибиться.

Типовые сценарии и быстрые решения

Сценарий 1: critical warning появился внезапно

• Сразу снимите nvme smart-log и nvme error-log.
• Проверьте, не включился ли read-only режим (бит 3 в critical_warning или сообщения в kernel log).
• Проверьте актуальность бэкапов и план миграции.
• Если есть RAID/репликация — инициируйте замену диска без ожидания «вторичных» симптомов.

Сценарий 2: растут media errors, но сервис «не падает»

• Считайте это деградацией и практическим predictive failure.
• Снимите динамику: значение сейчас и повторно через 1–2 часа (или быстрее под нагрузкой).
• Проверьте ФС по вашим регламентам, но помните: ФС не «вылечит» носитель.
• Планируйте замену/миграцию данных.

Сценарий 3: тормоза и timeouts, но media errors = 0

• Проверьте температуру и косвенные признаки троттлинга.
• Проверьте kernel log на AER/PCIe ошибки.
• Снимите nvme error-log и посмотрите динамику num_err_log_entries.
• Если доступно в рамках change-процесса — обновите прошивку/ядро и повторите наблюдение.

Частые вопросы

Можно ли полностью доверять percentage_used?

Это хороший индикатор направления и тренда, но не абсолютная гарантия. У разных моделей отличаются алгоритмы оценки ресурса. Используйте percentage_used для планирования замен и прогнозирования, но не как единственный критерий «диск точно жив/точно мёртв».

Нормально ли, что num_err_log_entries не ноль?

Иногда да: единичные записи могли появиться из-за редких событий (например, reset при инициализации). Ненормально — когда счётчик стабильно растёт, особенно вместе с timeout в ядре, деградацией latency или ненулевым critical_warning.

Чем полезен nvme-cli, если уже есть smartctl?

smartctl удобен для унификации, но nvme-cli чаще даёт более «нативный» доступ к NVMe-логам и диагностике (error log, self-test log, идентификаторы контроллера/namespace). Для расследований это обычно быстрее и информативнее.

Итог

Базовый мониторинг NVMe в Linux строится вокруг SMART/health (nvme smart-log), счётчиков media_errors и critical_warning, плюс корреляции с kernel log. Храните историю, следите за трендами и не игнорируйте ранние сигналы: NVMe может долго выглядеть «почти нормально», а затем быстро перейти в состояние, где восстановление становится дороже.

Если вы только настраиваете сервер под проекты и хотите, чтобы мониторинг дисков был частью «минимального базового набора», выбирайте тариф и ресурсы с запасом под логи и метрики на VDS — так проще держать историю показателей и реагировать на деградацию до аварии.