Страница заблокирована

Эта страница в данный момент заблокирована для редактирования другим пользователем. Вам придётся подождать, пока этот пользователь закончит редактирование или истечёт время блокировки.
В данный момент заблокировано пользователем 216.73.216.52
Блокировка истекает в 2026/11/10 19:12 (3 min)
Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
====== 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`` — для расследований и детализации.

==== Установка ====
<code bash>
apt update
apt install -y nvme-cli smartmontools
</code>

<code bash>
dnf install -y nvme-cli smartmontools
</code>

==== Быстрая инвентаризация NVMe в системе ====
<code bash>
lsblk -d -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN
nvme list
</code>

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

{{https://fastfox.pro/media/ai_icons/vps2.png?linkonly&nolink|FastFox VDS}}

**Облачный VDS‑сервер в России**
Аренда виртуальных серверов с моментальным развёртыванием инфраструктуры от 195 ₽/мес.


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

Основная команда для чтения NVMe SMART/health log:
<code bash>
nvme smart-log /dev/nvme0
</code>

На части систем/моделей лог доступен и по namespace:
<code bash>
nvme smart-log /dev/nvme0n1
</code>

Если сомневаетесь, начинайте с контроллера (``/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``** — «биография» диска и качество окружения (питание/сбросы).

{{https://fastfox.pro/assets/images/articles/1403/1_c5abb74a.png?linkonly&nolink|Пример вывода nvme smart-log с ключевыми полями SMART/health}}

==== Как интерпретировать critical warning (битовая маска) ====

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

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

Для контекста полезно собрать идентификаторы контроллера и namespace:
<code bash>
nvme id-ctrl /dev/nvme0
nvme id-ns /dev/nvme0n1
</code>

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

Если у вас уже есть мониторинг на базе smartmontools, NVMe отлично читается через ``smartctl``:
<code bash>
smartctl -a /dev/nvme0
</code>

Иногда полезно явно указать тип устройства:
<code bash>
smartctl -a -d nvme /dev/nvme0
</code>

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


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

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


{{https://fastfox.pro/media/ai_icons/speed-hosting-server.png?linkonly&nolink|Виртуальный хостинг FastFox}}
**Виртуальный хостинг для сайтов**
Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 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 ====
<code bash>
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'
</code>

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


==== NVMe error log: быстрый способ понять «что именно болит» ====
Даже когда ``critical_warning`` ещё нулевой, в error log могут появляться записи. Снимок error log:
<code bash>
nvme error-log /dev/nvme0
</code>

Если хотите увидеть больше записей:
<code bash>
nvme error-log /dev/nvme0 -e 256
</code>

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

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