Мониторинг и диагностика систем хранения: SMART, логи и метрики производительности в 2026 году

Диагностика системы хранения опирается на три источника данных: отчёт SMART накопителя, счётчики блочного слоя ядра и журналы контроллера вместе с файловой системой. Если из массива выпал диск, начинайте с логов и SMART. Если сервис отвечает медленно, а ошибок в журналах нет, начинайте с метрик производительности.

Опорные показатели, по которым видна деградация: IOPS, latency (задержка, await), throughput, глубина очереди, %util и cache hit ratio. Для жёсткого диска критичны атрибуты Reallocated_Sector_Ct (ID 5), Current_Pending_Sector (ID 197), Offline_Uncorrectable (ID 198) и UDMA_CRC_Error_Count (ID 199), для NVMe - поля Percentage Used, Available Spare и Media Errors. Базовая проверка сводится к четырём шагам: smartctl -H, iostat -x 1, dmesg -T, zpool status или mdadm --detail.

Что проверять в первую очередь: карта диагностики СХД

Порядок обхода зависит от симптома. При жалобах на скорость первым идёт iostat, при выпадении диска из RAID - dmesg и smartctl, при ошибках монтирования - файловая система и состояние пула. Общий каркас выглядит так:

1. Статус накопителя: smartctl -H /dev/sdX даёт PASSED или FAILED, smartctl -A показывает таблицу атрибутов.
2. Метрики производительности: iostat -x 1 и sar -d 1 5 показывают задержки, очередь и загрузку устройства.
3. Журналы ядра и контроллера: dmesg -T, journalctl -k, storcli /c0 show events.
4. Состояние массива и файловой системы: zpool status -v, mdadm --detail /dev/md0, fsck -n.

Симптом → инструмент: таблица быстрого выбора

Таблица задаёт точку входа, но не отменяет проверку остальных слоёв: ошибка файловой системы часто оказывается следствием сбоя диска, а высокая задержка - следствием проблем на кабеле или backplane. Полный регламент ежедневных, еженедельных и ежемесячных проверок с порогами тревоги разобран в руководстве Мониторинг и обслуживание системы хранения файлов: SMART, логи и профилактика в 2026 году.

SMART-атрибуты дисков: какие читать и как интерпретировать

SMART хранит набор атрибутов, у каждого есть ID, нормализованное значение (VALUE), худшее значение (WORST), порог (THRESH) и raw-значение. Диск получает статус FAILING_NOW, когда нормализованное значение опускается до порога или ниже. Для прогноза интереснее raw-значение: это абсолютный счётчик, и его динамика показывает скорость износа. У части моделей Seagate поле 5 кодируется в hex-виде и выглядит как 0/0/8, что означает 8 переназначенных секторов. Расшифровку сверяйте с документацией производителя конкретной модели.

Критические атрибуты HDD: пороги и что делать

Порядок действий при срабатывании: сначала копия данных, затем диагностика. Атрибут 199 почти никогда не связан с поверхностью диска, поэтому замена накопителя при растущем CRC часто не решает проблему, если кабель и backplane остались прежними.

Особенности SSD и NVMe: Wear Leveling, Percentage Used, Media Errors

HDD-пороги к твердотельным накопителям не применяются: у них нет ни шпинделя, ни секторов, переназначаемых физически. Для NVMe смотрите поля, которые отдаёт smartctl -a /dev/nvme0:

• Percentage Used: расчётный износ. Значение выше 80% означает, что пора планировать замену, выше 100% - накопитель вышел за расчётный ресурс.
• Available Spare: остаток резервной области. Падение ниже Available Spare Threshold производителя - тревога, замена без ожидания.
• Media and Data Integrity Errors: любые ненулевые значения означают деградацию, а рост счётчика ускоряет замену.
• Data Units Written: объём записи в блоках по 1000 умножить на 512 байт, отсюда считается фактический TBW.
• Unsafe Shutdowns: резкие выключения без корректного завершения, косвенный признак проблем с питанием.

У SATA SSD вместо этого набора используются Wear Leveling Count или SSD_Life_Left, Total_LBAs_Written и Reallocated_Event_Count. Набор атрибутов, их нормализация и доступность полей зависят от производителя, версии прошивки и способа подключения: USB-мост или RAID-контроллер могут отдавать урезанный отчёт либо скрывать его полностью.

Чтение SMART через smartctl: команды и сценарии

smartctl обращается к устройству напрямую, поэтому для SATA, SAS и NVMe нужны права root или sudo. Рабочий набор вызовов:

• smartctl --scan перечисляет устройства и типы интерфейсов, включая nvme0.
• smartctl -i /dev/sdX показывает модель, серийный номер, версию прошивки, форм-фактор и скорость интерфейса. Эти данные нужны при сверке с бюллетенями производителя по проблемным прошивкам.
• smartctl -H /dev/sdX выводит итог самотестирования: PASSED или FAILED.
• smartctl -A /dev/sdX печатает только таблицу атрибутов.
• smartctl -a /dev/sdX собирает информацию об устройстве, атрибуты и лог ошибок.
• smartctl -x /dev/sdX добавляет расширенные блоки: температуры SCT, логи самотестов, статистику чтения и записи.
• smartctl -t short /dev/sdX запускает короткий тест на 1-3 минуты, smartctl -t long /dev/sdX проверяет всю поверхность.
• smartctl -l selftest /dev/sdX и smartctl -l error /dev/sdX показывают результаты тестов и журнал ошибок ATA.
• smartctl -n standby,power /dev/sdX не будит спящий диск при регулярном опросе.
• smartctl -j отдаёт JSON, который удобно складывать в файл и разбирать скриптами.

Для NVMe команды те же, но вывод содержит контроллерные поля. Long-тест создаёт заметную нагрузку, а на HDD большого объёма идёт несколько часов, поэтому его ставят в окно обслуживания, а не в часы пиковой нагрузки.

SMART за RAID-контроллером: megaraid, mpt3sas, arcconf

Когда диски подключены к аппаратному RAID-контроллеру, /dev/sda - это виртуальный том, и обычный smartctl -a покажет данные контроллера, а не конкретного накопителя. Нужно указать тип pass-through и номер диска:

• smartctl -d megaraid,0 /dev/sda для LSI и Broadcom MegaRAID, где 0 - device id.
• smartctl -d sat+megaraid,0 /dev/sda, если накопитель отдаёт SMART по SATA-протоколу.
• storcli /c0/eall/sall show all выводит состояние всех дисков, storcli /c0/eall/sall show smart показывает детали по каждому устройству.
• arcconf GETCONFIG 1 PD для Adaptec и Microsemi.
• Другие семейства: smartctl -d 3ware,N, -d areca,N, -d aacraid,H,L,ID, -d cciss,N.

Часть контроллеров отдаёт урезанный набор атрибутов или скрывает SMART. Тогда единственный источник данных - CLI самого контроллера, а алерты строятся по его событиям. Device id меняются при перестановке дисков, поэтому в скриптах их лучше брать из вывода storcli, а не фиксировать вручную.

Прогнозирование отказов накопителей: тренды важнее порогов

Один замер отвечает на вопрос, что происходит с диском сейчас, но не показывает, что будет через неделю. Отказ по механике виден по динамике счётчиков: в открытом датасете Backblaze Drive Stats собрана статистика отказов сотен тысяч дисков, и рост числа неисправимых и переназначенных секторов там опережает выпадение накопителя из массива на дни и недели. Практический вывод: собирайте SMART по расписанию и следите за скоростью роста.

Рабочие ориентиры:

• Reallocated_Sector_Ct (ID 5) вырос с нуля до нескольких единиц за неделю: диск под замену, а не под наблюдение.
• Current_Pending_Sector (ID 197) больше нуля: сначала резервная копия, затем long-тест.
• Offline_Uncorrectable (ID 198) вырос после scrub или mdadm check: поверхность деградирует.
• UDMA_CRC_Error_Count (ID 199) растёт: меняйте кабель, проверяйте backplane и порт контроллера.

Скрытые ошибки выявляют фоновые проверки. ZFS находит и исправляет их при scrub (zpool scrub tank), mdadm - при check (echo check > /sys/block/md0/md/sync_action). Обе операции нагружают массив, поэтому их ставят в расписание и не запускают в момент инцидента.

Сбор истории SMART: cron, systemd timer, экспортёры

Простейший вариант - ежечасная запись в JSON-файл: строка crontab вида 0 * * * * /usr/sbin/smartctl -A -j /dev/sda >> /var/log/smart/sda.jsonl. Формат JSONL удобен тем, что каждая строка разбирается отдельно, а старые файлы ротируются через logrotate. Systemd timer делает то же самое, добавляя журналирование и зависимости от других юнитов.

Для централизованного сбора рядом с node_exporter ставят smartctl_exporter: экспортёр отдаёт метрики по всем дискам, а Prometheus хранит историю в TSDB. Глубина хранения 12-24 месяца позволяет сравнивать сезонные колебания и ловить медленную деградацию. Разбор такого контура с порогами и процедурами замены дисков есть в статье Система мониторинга и проактивного обслуживания дисковых массивов в 2026 году.

Метрики производительности СХД: IOPS, задержки, пропускная способность, кэш

Четыре группы метрик закрывают почти все вопросы по производительности: IOPS (операций в секунду), latency (задержка на операцию, await), throughput (пропускная способность в МБ/с) и глубина очереди (aqu-sz). Пятая, косвенная - заполненность кэша.

%util показывает долю времени, в течение которого устройство было занято. Устойчивое значение выше 80% означает насыщение, и дополнительная нагрузка даст только рост задержки. Обратная ситуация информативна не меньше: await 50 мс при %util 30% говорит о том, что узкое место находится в контроллере, кабеле, сети или файловой системе, а не в насыщении диска.

iostat и sar: снятие метрик и чтение вывода

iostat -x 1 печатает расширенную статистику по каждому устройству раз в секунду. Значимые поля: r/s и w/s (IOPS чтения и записи), rkB/s и wkB/s (throughput), r_await и w_await (задержка в миллисекундах с учётом очереди), aqu-sz (средняя глубина очереди), %util (загрузка устройства). Поле svctm в актуальных версиях sysstat помечено устаревшим и в расчётах SLA не используется.

sar -d 1 5 собирает те же данные, но умеет читать историю из файлов /var/log/sa: sar -d -f /var/log/sa/sa18 покажет, что происходило на дисках в прошлый вторник. Для NVMe полезен nvme smart-log /dev/nvme0 с температурой и счётчиками ошибок. Синтетические замеры делают через fio, например: fio --name=randread --rw=randread --bs=4k --iodepth=32 --numjobs=4 --runtime=60 --group_reporting. Такой прогон показывает потолок по IOPS и задержку конкретного пула.

Заполненность кэша: как измерять и когда это проблема

У RAID-контроллеров кэш виден через storcli /c0 show all: вывод содержит Cache Hit Ratio, Dirty Cache и состояние батареи или energy pack. Большой объём Dirty Cache при разряженной батарее переводит контроллер в режим write-through, и скорость записи падает в разы. Если Cache Hit Ratio держится ниже примерно 80% на рабочей нагрузке, объём кэша не соответствует профилю операций.

В ZFS роль кэша выполняет ARC. arc_summary -s arc и arcstat 1 показывают hit ratio, размер и распределение. По умолчанию ARC занимает до половины RAM (параметр zfs_arc_max), и низкий hit ratio обычно решается добавлением памяти или подбором recordsize, а не установкой L2ARC вслепую. Метрики хранилища и готовые дашборды разобраны в статье Мониторинг систем хранения данных: ключевые метрики и инструменты для администратора.

Логи контроллеров и файловых систем: как отличить аппаратную проблему от программной

Журналы отвечают на главный вопрос диагностики: проблема в железе или в программном слое. Смотрите четыре источника: dmesg -T (ядро с человекочитаемым временем), journalctl -k -p err, журналы контроллера (storcli /c0 show events, arcconf GETLOGS) и логи файловой системы в /var/log/messages или /var/log/syslog.

Алгоритм разбора инцидента:

1. dmesg -T | grep -i -E "error|fail|reset|timeout" собирает подозрительные строки с временем.
2. smartctl -a по устройству из сообщения показывает, есть ли рост атрибутов 5, 197, 198 и 199.
3. zpool status -v, fsck -n или xfs_repair -n проверяют целостность данных и метаданных.
4. Кабель, backplane и порт контроллера проверяются заменой, если продолжает расти CRC.

Практическое правило: повторяющиеся ошибки на одном и том же устройстве при исправных кабелях указывают на деградацию железа, а разовые ошибки после сбоя питания или обновления ядра чаще связаны с драйвером.

ZFS и mdadm: диагностика массива

zpool status -v печатает состояние пула, список ошибок и имена файлов, затронутых повреждением. zpool status -x коротко отвечает, всё ли в порядке. zpool events -v показывает поток событий, включая ошибки ввода-вывода и подключение устройств. ZFS исправляет ошибки только при наличии избыточности и только во время scrub: без регулярного zpool scrub tank повреждённый блок останется помеченным, но не восстановленным.

Для mdadm работают mdadm --detail /dev/md0, cat /proc/mdstat и mdadm --examine. Проверка целостности запускается записью check в /sys/block/md0/md/sync_action, результат виден в mismatch_cnt. Ненулевой mismatch_cnt на массиве без явных ошибок диска часто объясняется сбоями записи при отключении питания.

ext4 и XFS: чтение ошибок файловой системы

В ext4 ошибки видны в dmesg строками вида EXT4-fs error, что означает повреждение метаданных или журнала. Проверка выполняется на размонтированной файловой системе или смонтированной read-only: fsck -n /dev/sdX1 показывает проблемы без изменений, tune2fs -l и dumpe2fs выводят параметры. Для XFS аналог - xfs_repair -n /dev/sdX1 и xfs_info, работать с ними нужно при размонтированной файловой системе.

Если ошибки файловой системы повторяются на одном и том же устройстве, а атрибуты SMART растут, причина в накопителе, а не в программном обеспечении. Обратный случай - единичные сбои после аварийного выключения, здесь помогает проверка и восстановление журнала. Полную поверхностную проверку HDD выполняют через badblocks -sv в режиме чтения.

Настройка оповещений и регулярных проверок

Оповещения строятся на двух уровнях: локальный smartd для быстрых предупреждений и централизованный стек Prometheus или Zabbix для истории и корреляции. Пороги задаются по абсолютным значениям и по скорости роста, иначе однократный скачок счётчика даст ложное срабатывание.

smartd: конфиг и типовые ошибки

Базовая строка в /etc/smartd.conf: DEVICESCAN -a -o on -S on -s (S/../.././02|L/../../7/03) -W 4,45,55 -m admin@example.com -M daily. Флаги означают: -a проверять все атрибуты, -o on запускать offline-тест автоматически, -S on сохранять атрибуты между перезагрузками, -s задаёт расписание (short-тест ежедневно в 02:00, long-тест по воскресеньям в 03:00), -W 4,45,55 включает контроль температуры, -m и -M отвечают за адрес уведомлений и частоту писем. После правки файла службу перезапускают: systemctl restart smartd.

Типичные ошибки: smartd не видит диски за RAID-контроллером (нужен -d megaraid,N или -d sat+megaraid,N), контроль температуры не работает на части USB-мостов, а опрос без -n standby не даёт диску уснуть. Настройка тестов и уведомлений в TrueNAS с разбором атрибутов HDD и SSD описана в руководстве Настройка и интерпретация SMART-мониторинга в TrueNAS: полное руководство.

Prometheus и Grafana: алерты по SMART и метрикам

smartctl_exporter слушает порт 9633 и отдаёт метрики, которые забирает Prometheus. Основные ряды: smartctl_device_smart_status (1 - здоров, 0 - FAILED), smartctl_device_attribute с метками attribute_id и attribute_name, smartctl_device_media_errors, smartctl_device_percentage_used, smartctl_device_available_spare. Метрики производительности приходят из node_exporter: node_disk_read_time_seconds_total, node_disk_write_time_seconds_total и node_disk_io_time_seconds_total позволяют считать средние задержки и загрузку запросами PromQL.

Рабочие условия для алертов: smartctl_device_smart_status != 1, рост атрибута 5 за 24 часа больше нуля, smartctl_device_percentage_used > 80, smartctl_device_media_errors > 0, smartctl_device_available_spare ниже порога производителя. Скорость роста считается через increase() или deriv() по окну 24-72 часа. Дашборды для дежурного и структуру алертов в Alertmanager и Zabbix разбирает статья Мониторинг и диагностика СХОД: метрики, логи и алерты для дисков, RAID и производительности.

Чек-лист регулярных проверок СХД

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

• Ежедневно: smartctl -H по всем дискам, iostat -x 1 5 на активных массивах, dmesg -T | grep -i -E "error|fail", df -h и df -i, состояние алертов и статус пулов.
• Еженедельно: smartctl -t short, zpool status -x, mdadm --detail /dev/md0, Cache Hit Ratio и состояние батареи контроллера, просмотр свежих записей в журнале событий контроллера.
• Ежемесячно: smartctl -t long, zpool scrub, mdadm check, тестовое восстановление данных из резервной копии, проверка свободного места с учётом прогноза роста.
• Ежеквартально: аудит трендов SMART за три месяца, сверка версий прошивок дисков и контроллеров с рекомендациями производителя, пересмотр порогов алертов, инвентаризация сроков гарантии.

Начните с одного действия, которое даёт максимальный эффект: включите сбор SMART по расписанию и алерт на рост атрибутов 5, 197 и 199. Дальше добавляйте long-тесты, scrub и дашборды, опираясь на тренды, а не на разовые замеры.

Источники

• Acer Recovery Menu: BIOS, F12 Boot, and Safe Options — материал по меню восстановления, BIOS/UEFI и режимам SATA/VMD на компьютерах Acer; полезен как смежный источник по настройкам контроллера хранения.

Материалы Research Pack не покрывают напрямую темы SMART, логов контроллеров и файловых систем, метрик производительности и настройки оповещений, поэтому приведённые в статье практики опираются на общепринятые инструменты и команды, а не на подтверждённые первоисточники по каждому утверждению.