======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, а многие логи читаются с контроллера. ====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 поля. Для мониторинга важнее динамика и пересечение порогов, чем совпадение цифр «до последнего знака». ====Ошибка носителя (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) или подключить агент мониторинга, который собирает метрики структурированно. ====Типовые сценарии и быстрые решения==== =====Сценарий 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 может долго выглядеть «почти нормально», а затем быстро перейти в состояние, где восстановление становится дороже.