Различия

Показаны различия между двумя версиями страницы.

--- nvme-linux-smart-health [2026/02/27 00:45] – admin
+++ nvme-linux-smart-health [2026/02/27 01:04] (текущий) – admin
@@ Строка 1: / Строка 1: @@
-====== NVMe в Linux: SMART и Health для мониторинга дисков ======
+======NVMe в Linux: SMART и Health для мониторинга дисков======
-==== Зачем администратору смотреть SMART/health у NVMe ====
+====Зачем администратору смотреть SMART/health у NVMe====
 NVMe‑диски часто деградируют «не как SATA»: сначала растёт latency ступеньками, появляются предупреждения контроллера и записи в NVMe‑логах, а явные ошибки в файловой системе могут проявиться уже позже.
@@ Строка 12: / Строка 11: @@
 На практике мониторинг NVMe закрывает три задачи:
-  * **Disk health monitoring** — видеть условия работы и текущий статус (температура, ресурс, циклы питания).
+* **Disk health monitoring** — видеть условия работы и текущий статус (температура, ресурс, циклы питания).
-  * **Predictive failure** — ловить ранние признаки деградации (рост ``media_errors``, записи в error log, корреляция с timeouts).
+* **Predictive failure** — ловить ранние признаки деградации (рост ``media_errors``, записи в error log, корреляция с timeouts).
-  * **Триаж инцидентов** — быстро отделить проблему диска от проблем выше (ФС, RAID, питание, PCIe, драйвер, прошивка).
+* **Триаж инцидентов** — быстро отделить проблему диска от проблем выше (ФС, RAID, питание, PCIe, драйвер, прошивка).
 Ниже — практический чек‑лист и команды, которые реально помогают на серверах и виртуалках с NVMe.
-==== Инструменты: nvme‑cli и smartctl для NVMe ====
+====Инструменты: nvme‑cli и smartctl для NVMe====
 Для NVMe в Linux обычно используют два инструмента:
-  * **``nvme-cli``** — «родной» доступ к NVMe‑логам: SMART/health, error log, self‑test log, идентификаторы контроллера/namespace.
+* **``nvme-cli``** — «родной» доступ к NVMe‑логам: SMART/health, error log, self‑test log, идентификаторы контроллера/namespace.
-  * **``smartctl``** (smartmontools) — универсальный вывод, удобно, если у вас уже есть единый пайплайн мониторинга под SATA/SAS и NVMe.
+* **``smartctl``** (smartmontools) — универсальный вывод, удобно, если у вас уже есть единый пайплайн мониторинга под SATA/SAS и NVMe.
 В проде удобно держать оба: ``smartctl`` — для унификации алертов, ``nvme-cli`` — для расследований и детализации.
-==== Установка ====
+====Установка====
 <code bash>
 apt update
@@ Строка 36: / Строка 40: @@
 </code>
-==== Быстрая инвентаризация NVMe в системе ====
+====Быстрая инвентаризация NVMe в системе====
 <code bash>
 lsblk -d -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN
@@ Строка 45: / Строка 49: @@
-==== SMART/health через nvme‑cli: база, которую стоит знать ====
+====SMART/health через nvme‑cli: база, которую стоит знать====
 Основная команда для чтения NVMe SMART/health log:
@@ Строка 59: / Строка 63: @@
 Если сомневаетесь, начинайте с контроллера (``/dev/nvme0``) и проверяйте, что вывод содержит осмысленные значения.
-==== Ключевые поля: что смотреть в первую очередь ====
+====Ключевые поля: что смотреть в первую очередь====
 Названия могут слегка отличаться, но смысл и набор полей обычно стандартны. Для мониторинга я бы выделил:
-  * **``critical_warning``** — сводный битовый флаг критических состояний. Ноль — нормально, неноль — повод разбираться сразу.
+* **critical_warning** — сводный битовый флаг критических состояний. Ноль — нормально, неноль — повод разбираться сразу.
-  * **``temperature``** — текущая температура (перегрев даёт троттлинг и ускоряет деградацию).
+* **temperature** — текущая температура (перегрев даёт троттлинг и ускоряет деградацию).
-  * **``available_spare``** и **``available_spare_threshold``** — запас по резервным блокам и порог.
+* **available_spare** и **available_spare_threshold** — запас по резервным блокам и порог.
-  * **``percentage_used``** — оценка «израсходованного ресурса» (0–100+). Это не «процент оставшегося времени», а индикатор того, что ресурс выработан на N % по оценке контроллера.
+* **percentage_used** — оценка «израсходованного ресурса» (0–100+). Это не «процент оставшегося времени», а индикатор того, что ресурс выработан на N % по оценке контроллера.
-  * **``media_errors``** — один из самых важных индикаторов: неисправимые ошибки носителя/целостности.
+* **media_errors** — один из самых важных индикаторов: неисправимые ошибки носителя/целостности.
-  * **``num_err_log_entries``** — количество записей в NVMe error log (важнее динамика, чем «сам факт»).
+* **num_err_log_entries** — количество записей в NVMe error log (важнее динамика, чем «сам факт»).
-  * **``power_on_hours``**, **``power_cycles``**, **``unsafe_shutdowns``** — «биография» диска и качество окружения (питание/сбросы).
+* **power_on_hours**, **power_cycles**, **unsafe_shutdowns** — «биография» диска и качество окружения (питание/сбросы).
+====Как интерпретировать critical warning (битовая маска)====
-==== Как интерпретировать critical warning (битовая маска) ====
-Поле ``critical_warning`` — битовая маска. Точная расшифровка зависит от версии спецификации и реализации, но часто встречается такая логика:
+Поле **critical_warning** — битовая маска. Точная расшифровка зависит от версии спецификации и реализации, но часто встречается такая логика:
-  * бит 0: ``available_spare`` ниже порога;
+* бит 0: available_spare ниже порога;
-  * бит 1: температура вышла за пределы (over/under temperature);
+* бит 1: температура вышла за пределы (over/under temperature);
-  * бит 2: деградация надёжности (device reliability degraded);
+* бит 2: деградация надёжности (device reliability degraded);
-  * бит 3: устройство в режиме «только чтение»;
+* бит 3: устройство в режиме «только чтение»;
-  * бит 4: требуется backup / критический ресурс.
+* бит 4: требуется backup / критический ресурс.
+> Практическое правило: critical_warning не равен нулю — это не история «понаблюдаем», а повод немедленно проверить логи, актуальность бэкапов и план замены.
-> Практическое правило: ``critical_warning`` не равен нулю — это не история «понаблюдаем», а повод немедленно проверить логи, актуальность бэкапов и план замены.
 Для контекста полезно собрать идентификаторы контроллера и namespace:
@@ Строка 88: / Строка 95: @@
 </code>
-==== SMART через smartctl: когда нужен единый подход ====
+====SMART через smartctl: когда нужен единый подход====
-Если у вас уже есть мониторинг на базе smartmontools, NVMe отлично читается через ``smartctl``:
+Если у вас уже есть мониторинг на базе smartmontools, NVMe отлично читается через **smartctl**:
 <code bash>
 smartctl -a /dev/nvme0
 </code>
 Иногда полезно явно указать тип устройства:
@@ Строка 100: / Строка 109: @@
 </code>
-В выводе ищите аналоги: ``Critical Warning``, ``Media and Data Integrity Errors``, ``Percentage Used``, температуру и счётчики ``Power On Hours``/``Unsafe Shutdowns``.
+В выводе ищите аналоги: Critical Warning, Media and Data Integrity Errors, Percentage Used, температуру и счётчики Power On Hours/Unsafe Shutdowns.
+====Почему значения в nvme‑cli и smartctl могут отличаться====
-==== Почему значения в nvme‑cli и smartctl могут отличаться ====
 Чаще всего отличия — это формат представления (например, smartmontools пересчитывает data units в удобные объёмы), а также vendor‑specific поля. Для мониторинга важнее динамика и пересечение порогов, чем совпадение цифр «до последнего знака».
+====Ошибка носителя (media errors): что считать нормой, а что нет====
-==== Ошибка носителя (media errors): что считать нормой, а что нет ====
-``media_errors`` (в smartctl обычно ``Media and Data Integrity Errors``) — счётчик неисправимых ошибок носителя/целостности. В идеале он равен нулю и остаётся нулём.
+**media_errors** (в smartctl обычно Media and Data Integrity Errors) — счётчик неисправимых ошибок носителя/целостности. В идеале он равен нулю и остаётся нулём.
+Если **media_errors** стал больше нуля, действуйте по плану:
+. **Зафиксируйте текущее значение** и начните смотреть динамику (рост важнее абсолютного значения).
+. **Снимите NVMe error log** и проверьте повторяемость/тип ошибок.
+. **Проверьте kernel log** на reset/timeout/AER и корреляцию по времени.
+. **Сократите риск**: проверьте бэкапы/репликацию, подготовьте миграцию данных.
+. **Планируйте замену**: растущий media_errors в проде — это практический predictive failure.
-Если ``media_errors`` стал больше нуля, действуйте по плану:
+====Где ещё видно признаки проблем: dmesg и journalctl====
-. **Зафиксируйте текущее значение** и начните смотреть динамику (рост важнее абсолютного значения).
-. **Снимите NVMe error log** и проверьте повторяемость/тип ошибок.
-. **Проверьте kernel log** на reset/timeout/AER и корреляцию по времени.
-. **Сократите риск**: проверьте бэкапы/репликацию, подготовьте миграцию данных.
-. **Планируйте замену**: растущий ``media_errors`` в проде — это практический predictive failure.
-==== Где ещё видно признаки проблем: dmesg и journalctl ====
 <code bash>
 dmesg -T | grep -iE 'nvme|pcie|aer|timeout|reset|I/O error'
@@ Строка 127: / Строка 135: @@
 </code>
-Регулярные reset/timeout могут означать как деградацию диска, так и проблемы окружения (PCIe, питание, прошивка, температурный режим, драйвер). Поэтому всегда смотрите связку: kernel log + рост ``num_err_log_entries`` + рост ``media_errors`` + жалобы приложений на latency.
+Регулярные reset/timeout могут означать как деградацию диска, так и проблемы окружения (PCIe, питание, прошивка, температурный режим, драйвер). Поэтому всегда смотрите связку: kernel log + рост num_err_log_entries + рост media_errors + жалобы приложений на latency.
+====NVMe error log: быстрый способ понять «что именно болит»====
-==== NVMe error log: быстрый способ понять «что именно болит» ====
-Даже когда ``critical_warning`` ещё нулевой, в error log могут появляться записи. Снимок error log:
+Даже когда **critical_warning** ещё нулевой, в error log могут появляться записи. Снимок error log:
 <code bash>
 nvme error-log /dev/nvme0
 </code>
 Если хотите увидеть больше записей:
@@ Строка 140: / Строка 150: @@
 nvme error-log /dev/nvme0 -e 256
 </code>
 На что смотреть в первую очередь:
-  * повторяемость одного и того же статуса/ошибки;
+* повторяемость одного и того же статуса/ошибки;
-  * связь по времени с просадками производительности и таймаутами в ядре;
+* связь по времени с просадками производительности и таймаутами в ядре;
-  * появление ошибок после обновления ядра или изменения прошивки/BIOS.
+* появление ошибок после обновления ядра или изменения прошивки/BIOS.
+> Если error log растёт, но **media_errors** остаётся нулём — это ещё не приговор. Но это повод проверить термальный режим, стабильность PCIe, версию прошивки и паттерн нагрузки.
+====Self‑test для NVMe: когда он полезен и как запускать====
+Многие NVMe поддерживают self‑test. Наличие и поведение зависят от модели и платформы, поэтому проверяйте результат и влияние на производительность в тестовом окне.
+Просмотр self‑test log:
+<code bash>
+nvme self-test-log /dev/nvme0
+</code>
+Запуск короткого теста (если поддерживается):
+<code bash>
+nvme device-self-test /dev/nvme0 --self-test-code=1
+</code>
+Запуск расширенного теста:
+<code bash>
+nvme device-self-test /dev/nvme0 --self-test-code=2
+</code>
+====Температура и троттлинг: скрытая причина «странных тормозов»====
+NVMe чувствительны к перегреву: при достижении порогов контроллер включает thermal throttling, и вы получаете всплески latency даже без явных ошибок чтения/записи.
+Базовая проверка — снова SMART/health:
+<code bash>
+nvme smart-log /dev/nvme0
+</code>
+Если температура регулярно высокая:
+* на «железе» проверьте 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 минут, по ситуации):
+<code bash>
+date -Is; nvme smart-log /dev/nvme0; echo
+</code>
+Альтернатива через smartmontools:
+<code bash>
+date -Is; smartctl -a /dev/nvme0; echo
+</code>
+Дальше можно парсить конкретные строки (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 может долго выглядеть «почти нормально», а затем быстро перейти в состояние, где восстановление становится дороже.
-> Если error log растёт, но ``media_errors`` остаётся нулём — это ещё не приговор. Но это повод проверить термальный режим, стабильность PCIe, версию прошивки и