Мониторинг S.M.A.R.T. в Linux: полное руководство по настройке, анализу и оповещениям

Внезапный отказ диска без предупреждения - одна из главных угроз для серверной инфраструктуры. Технология S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) встроена в большинство современных HDD и SSD и позволяет выявить признаки деградации за дни или недели до полного выхода накопителя из строя. По данным исследований Google и Backblaze, более 60% отказов жестких дисков предсказуемы по изменениям ключевых S.M.A.R.T.-атрибутов до того, как диск перестанет отвечать.

Пакет smartmontools - стандартный инструмент для работы с S.M.A.R.T. в Linux. Он включает две основные утилиты: smartctl для ручной диагностики и запуска тестов, и smartd - демон для автоматического мониторинга с отправкой оповещений при обнаружении проблем. Это руководство проведет вас от установки пакета до настройки полностью автоматизированной системы, которая предупредит о критическом износе SSD, нестабильных секторах на HDD или превышении температурного порога.

Мониторинг S.M.A.R.T. не заменяет резервное копирование. Это первый эшелон обороны - инструмент, который дает время на плановую замену диска и спокойную миграцию данных. Если вы еще не знакомы с диагностикой дисков в других ОС, посмотрите обзор инструментов мониторинга дисков в Windows. Принципы интерпретации атрибутов там схожи, а различия касаются только интерфейса.

Зачем нужен мониторинг S.M.A.R.T. и как он спасает данные

S.M.A.R.T. собирает десятки метрик о состоянии механики, электроники и поверхности диска. Контроллер накопителя непрерывно обновляет эти значения, а утилиты вроде smartctl позволяют их прочитать. Ключевое преимущество проактивного мониторинга - вы получаете сигнал о проблеме не тогда, когда данные уже потеряны, а на этапе накопления ошибок.

Типичный сценарий для HDD: значение атрибута Reallocated_Sector_Ct начинает расти. Это означает, что диск обнаруживает сбойные сектора и переназначает их из резервной области. Единичные переназначения допустимы, но устойчивый рост в течение нескольких дней - прямой индикатор деградирующей поверхности. Без мониторинга администратор узнает о проблеме только когда резервная область исчерпается и файловая система начнет терять данные.

Для SSD критичен износ ячеек памяти. Атрибут Media_Wearout_Indicator показывает оставшийся ресурс в процентах. Когда он приближается к нулю, запись в ячейки становится невозможной. SSD может внезапно перейти в режим «только чтение», что для серверной нагрузки равносильно отказу. Регулярная проверка этого атрибута позволяет спланировать замену за несколько месяцев.

Мониторинг должен быть автоматическим. Ручные проверки раз в месяц пропускают момент начала деградации. Демон smartd решает эту задачу: он опрашивает диски по расписанию, сравнивает значения атрибутов с порогами и отправляет уведомления при отклонениях. Настроенная система мониторинга S.M.A.R.T. в сочетании с регулярными бэкапами - минимальный стандарт для любого production-окружения.

Установка и первый запуск smartmontools

Пакет smartmontools доступен в репозиториях всех основных дистрибутивов Linux. Установка занимает одну команду.

Debian, Ubuntu и производные:

sudo apt update && sudo apt install smartmontools

RHEL, CentOS, Rocky Linux, AlmaLinux (с EPEL):

sudo dnf install smartmontools

После установки демон smartd запускается автоматически и начинает мониторинг с базовой конфигурацией. Базовая конфигурация использует директиву DEVICESCAN, которая обнаруживает все блочные устройства и применяет к ним стандартные проверки. Для production-среды базовую конфигурацию нужно заменить на явное описание каждого диска с кастомными порогами, но для первого знакомства она подходит.

Как проверить, поддерживает ли диск S.M.A.R.T.

Перед настройкой мониторинга убедитесь, что диск поддерживает технологию и она активирована. Команда для проверки:

sudo smartctl -i /dev/sda

В выводе найдите строки:

SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Если поддержка Available, но не Enabled, включите её:

sudo smartctl -s on /dev/sda

Если вывод показывает «SMART support is: Unavailable», диск не поддерживает технологию. Это редкость для современных накопителей, но встречается в старых SCSI-дисках или специфических моделях. В виртуальных машинах поддержка S.M.A.R.T. зависит от гипервизора: VMware и Proxmox позволяют пробросить S.M.A.R.T. от физического диска, облачные VPS обычно эмулируют минимальный набор атрибутов или не поддерживают технологию вовсе.

Иногда S.M.A.R.T. отключен в BIOS/UEFI сервера. Проверьте настройки SATA-контроллера при загрузке - опция может называться «S.M.A.R.T. Status Check» или «HDD S.M.A.R.T. Capability».

Быстрая оценка состояния: команда smartctl -H

Для быстрой проверки общего статуса диска используйте:

sudo smartctl -H /dev/sda

Вывод содержит одну из двух строк:

SMART overall-health self-assessment test result: PASSED

или

SMART overall-health self-assessment test result: FAILED!

PASSED означает, что ни один из критических атрибутов не достиг порогового значения, установленного производителем. Это хороший знак, но не гарантия полной исправности. Диск может иметь сотни переназначенных секторов, которые пока ниже порога, или медленно растущий счетчик ошибок, еще не достигший критической отметки. Именно поэтому разовая проверка через -H дополняется регулярным мониторингом и анализом сырых значений атрибутов.

FAILED - сигнал к немедленной замене диска. Порог производителя пересечен, диск считает себя неисправным. Сделайте резервную копию данных и замените накопитель при первой возможности.

Ключевые атрибуты S.M.A.R.T. и их интерпретация

Полный список атрибутов выводится командой:

sudo smartctl -A /dev/sda

Таблица содержит столбцы: ID - идентификатор атрибута, ATTRIBUTE_NAME - название, VALUE - текущее нормализованное значение (обычно от 1 до 100 или 200, где выше - лучше), WORST - наихудшее зафиксированное значение, THRESH - порог, при котором диск сигнализирует об отказе, RAW_VALUE - сырое значение в единицах, специфичных для каждого атрибута.

Принцип интерпретации: если VALUE опускается ниже THRESH, диск сообщает о проблеме (тот самый FAILED в smartctl -H). Сырые значения важны для выявления трендов. Рост RAW_VALUE при стабильном VALUE - ранний признак деградации, который стоит отслеживать.

Атрибуты, указывающие на скорый отказ HDD

Для жестких дисков критичны три атрибута, связанных с состоянием поверхности пластин:

Reallocated_Sector_Ct (ID 5) - количество переназначенных секторов. Сбойные сектора заменяются на резервные. Ненулевое значение допустимо, но рост этого счетчика - главный индикатор деградации. Если значение увеличивается каждую неделю, диск нужно менять. Разовый скачок на десятки или сотни секторов - признак серьезного механического повреждения.
Current_Pending_Sector (ID 197) - сектора, которые диск считает нестабильными, но еще не переназначил. Они ждут повторного чтения или записи для принятия решения. Ненулевое значение этого атрибута часто сопровождается ошибками ввода-вывода в системных логах. Если после принудительной перезаписи этих секторов значение не обнуляется, диск неисправен.
Offline_Uncorrectable (ID 198) - сектора, которые не удалось прочитать во время фонового сканирования. В отличие от Current_Pending_Sector, эти сектора уже признаны неисправными. Появление этого атрибута - серьезный сигнал, особенно в сочетании с ростом Reallocated_Sector_Ct.

Практическое правило: если сумма Reallocated_Sector_Ct, Current_Pending_Sector и Offline_Uncorrectable превышает 0 и растет - планируйте замену диска. Для детального сравнения утилит диагностики, включая кроссплатформенные решения, обратитесь к обзору CrystalDiskInfo, HD Tune и GSmartControl.

Специфичные атрибуты SSD и их значение

Твердотельные накопители имеют другую физику отказов. Механического износа нет, но ячейки NAND-памяти имеют ограниченное количество циклов перезаписи. Ключевые атрибуты для SSD:

Media_Wearout_Indicator (ID varies) - оставшийся ресурс в процентах. Производители устанавливают начальное значение 100, которое уменьшается по мере износа. При значении 1-5% диск близок к исчерпанию ресурса записи.
Wear_Leveling_Count (ID varies) - количество циклов перезаписи, усредненное по всем ячейкам. Характеризует общий износ. Сравнивайте с заявленным производителем ресурсом (TBW - Total Bytes Written).
Program_Fail_Count и Erase_Fail_Count - ошибки программирования и стирания ячеек. Ненулевые значения указывают на деградацию контроллера или чипов памяти. Даже единичные сбои здесь - повод для пристального наблюдения.

Для NVMe-накопителей стандартные S.M.A.R.T.-атрибуты через smartctl доступны, но полную картину дает утилита nvme-cli. Рекомендуем изучить руководство по ключевым метрикам здоровья SSD, где разобраны формулы расчета оставшегося ресурса и скрипты оповещений для NVMe-дисков.

Настройка автоматического мониторинга с помощью smartd

Ручные проверки полезны для диагностики, но постоянный мониторинг требует автоматизации. Демон smartd работает в фоне, периодически опрашивает диски и сравнивает значения атрибутов с порогами. При обнаружении отклонений он выполняет заданные действия: отправляет email, пишет в syslog, запускает внешний скрипт.

Конфигурационный файл: /etc/smartd.conf. Синтаксис: каждая строка описывает одно устройство или группу устройств. Формат строки:

/dev/device -options

Директива DEVICESCAN в стандартной конфигурации сканирует все блочные устройства. Для точной настройки её комментируют и описывают каждый диск отдельно.

Создание конфигурации smartd для типовых сценариев

Рассмотрим три типовых конфигурации.

Одиночный системный диск (HDD):

/dev/sda -a -o on -S on -s (S/../.././02|L/../../7/03) -m admin@example.com

Разбор опций:

-a - эквивалент -H -f -t -l error -l selftest -C 197 -U 198. Включает мониторинг здоровья, атрибутов, ошибок и результатов самотестов.
-o on - включает автоматические офлайн-тесты диска (выполняются контроллером самостоятельно).
-S on - включает сохранение атрибутов между перезагрузками.
-s (S/../.././02|L/../../7/03) - расписание тестов: короткий (S) каждую ночь в 02:00, длинный (L) каждое воскресенье в 03:00.
-m admin@example.com - адрес для уведомлений.

Сервер с несколькими дисками в RAID:

/dev/sda -a -o on -S on -s (S/../.././02|L/../../7/03) -m admin@example.com
/dev/sdb -a -o on -S on -s (S/../.././02|L/../../7/04) -m admin@example.com
/dev/sdc -a -o on -S on -s (S/../.././02|L/../../7/05) -m admin@example.com

Смещение времени длинных тестов на час для каждого диска снижает пиковую нагрузку на контроллер.

SSD-накопитель:

/dev/nvme0n1 -a -o on -S on -s (S/../.././02) -m admin@example.com

Для SSD длинные тесты поверхности не имеют смысла - нет пластин. Ограничиваемся короткими самотестами и отслеживанием атрибутов износа. Для NVMe-дисков путь к устройству указывается как /dev/nvme0n1.

После изменения конфигурации перезапустите демон:

sudo systemctl restart smartd

Проверьте статус и логи:

sudo systemctl status smartd
sudo journalctl -u smartd -f

Настройка email-оповещений: от простого к расширенному

Опция -m в smartd.conf отправляет письма через системную команду mail. В минимальных серверных установках почтовый агент (MTA) часто отсутствует. Решение - настроить легковесный релей через внешний SMTP-сервер с помощью msmtp или ssmtp.

Установка msmtp:

sudo apt install msmtp msmtp-mta

Конфигурация /etc/msmtprc для релея через SMTP-сервер (пример для корпоративного сервера):

defaults
auth on
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile /var/log/msmtp.log

account default
host smtp.company.com
port 587
user monitoring@company.com
password your_password
from monitoring@company.com

Права доступа к файлу с паролем:

sudo chmod 600 /etc/msmtprc

Тест отправки письма:

echo "Test from smartd" | mail -s "SMART Test" admin@example.com

Для кастомизации уведомлений используйте опцию -M exec вместо -m. Она запускает внешний скрипт при срабатывании, передавая ему информацию о проблеме через переменные окружения. Пример скрипта /usr/local/bin/smartd-notify.sh:

#!/bin/bash
# $SMARTD_DEVICE - устройство
# $SMARTD_MESSAGE - описание предупреждения
# $SMARTD_FAILTYPE - тип ошибки

/usr/sbin/smartctl -A $SMARTD_DEVICE | mail -s "SMART Alert: $SMARTD_FAILTYPE on $SMARTD_DEVICE" admin@example.com

Строка в smartd.conf для этого скрипта:

/dev/sda -a -M exec /usr/local/bin/smartd-notify.sh

Такой подход включает полный вывод атрибутов в тело письма, что ускоряет диагностику.

Интеграция с системами мониторинга (Zabbix, Prometheus)

Email-оповещения - минимальный уровень. В инфраструктуре с централизованным мониторингом данные S.M.A.R.T. передаются в Zabbix или Prometheus для построения дашбордов и настройки алертов с эскалацией.

Интеграция с Zabbix: демон smartd вызывает скрипт при каждом опросе, скрипт отправляет данные через zabbix_sender. Пример скрипта-обработчика:

#!/bin/bash
# Отправка ключевых атрибутов в Zabbix
DEVICE=$1
HOST=$(hostname)

# Извлекаем значения атрибутов
REALLOC=$(smartctl -A $DEVICE | grep Reallocated_Sector_Ct | awk '{print $10}')
PENDING=$(smartctl -A $DEVICE | grep Current_Pending_Sector | awk '{print $10}')
TEMP=$(smartctl -A $DEVICE | grep Temperature_Celsius | awk '{print $10}')

zabbix_sender -z zabbix.example.com -s "$HOST" -k smart.reallocated[$DEVICE] -o "$REALLOC"
zabbix_sender -z zabbix.example.com -s "$HOST" -k smart.pending[$DEVICE] -o "$PENDING"
zabbix_sender -z zabbix.example.com -s "$HOST" -k smart.temp[$DEVICE] -o "$TEMP"

Подробная инструкция по настройке шаблонов, LLD-обнаружению и кастомным триггерам - в руководстве по мониторингу дисков в Zabbix.

Интеграция с Prometheus: node_exporter включает коллектор для S.M.A.R.T. через скрипт smartmon.sh. Включите его при запуске node_exporter:

node_exporter --collector.textfile.directory=/var/lib/node_exporter/textfile_collector

Добавьте запуск smartmon.sh в cron:

*/5 * * * * /usr/local/bin/smartmon.sh > /var/lib/node_exporter/textfile_collector/smartmon.prom

Метрики появятся в Prometheus как smartmon_*, и вы сможете настроить алерты на критические значения атрибутов через Alertmanager.

Диагностика и устранение типичных проблем

При настройке мониторинга S.M.A.R.T. администраторы сталкиваются с несколькими повторяющимися проблемами. Разберем их решения.

Мониторинг дисков за аппаратными RAID-контроллерами

Аппаратные RAID-контроллеры скрывают физические диски за логическим устройством. Команда smartctl /dev/sda в таком случае обращается к виртуальному диску RAID, а не к физическому накопителю. Для доступа к S.M.A.R.T. отдельных дисков используется опция -d с указанием типа контроллера.

LSI MegaRAID (Dell PERC, IBM ServeRAID):

smartctl -a -d megaraid,0 /dev/sda

Где 0 - номер физического диска в массиве. Список всех дисков:

smartctl --scan | grep megaraid

3ware контроллеры:

smartctl -a -d 3ware,0 /dev/twa0

HP Smart Array (cciss, hpsa):

smartctl -a -d cciss,0 /dev/sg0

В конфигурации smartd для RAID-дисков укажите тип контроллера:

/dev/sda -d megaraid,0 -a -m admin@example.com
/dev/sda -d megaraid,1 -a -m admin@example.com

Что делать, если smartd выдает ложные тревоги

Старые диски с высокими, но стабильными значениями атрибутов часто вызывают ложные срабатывания. Например, диск проработал 5 лет, имеет 50 переназначенных секторов, но это значение не меняется последние полгода. Стандартные пороги производителя могут быть слишком консервативны для такого сценария.

Решение - переопределить пороги для конкретных атрибутов через опции smartd:

-C ID[+] - отслеживать изменение атрибута ID. Срабатывание только при увеличении значения.
-U ID[+] - аналогично, но для offline uncorrectable секторов.
-R ID - игнорировать атрибут ID полностью.

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

/dev/sda -a -C 5+ -m admin@example.com

Опция -C 5+ говорит smartd: «отслеживай атрибут 5 (Reallocated_Sector_Ct) и сообщай только если его raw-значение увеличилось». Это устраняет ежедневные письма о проблеме, которая не прогрессирует.

Перед отключением мониторинга любого атрибута выполните ручную верификацию: проверьте историю значений, запустите короткий и длинный самотесты. Ложное срабатывание - это стабильное значение, а не игнорируемая проблема.

Плановые тесты и интерпретация результатов самотестов

Пассивный мониторинг атрибутов дополняется активными самотестами, которые проверяют поверхность диска и механику. S.M.A.R.T. определяет три типа тестов:

Short - быстрая проверка электроники, механики и небольшого участка поверхности. Длительность: 1-2 минуты.
Long - полная проверка всей поверхности. Длительность: от десятков минут до нескольких часов, пропорционально объему диска.
Conveyance - тест для выявления повреждений, полученных при транспортировке. Редко используется в production, актуален для новых дисков перед вводом в эксплуатацию.

Запуск теста вручную:

sudo smartctl -t short /dev/sda
sudo smartctl -t long /dev/sda

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

sudo smartctl -c /dev/sda | grep "Self-test"

Просмотр результатов после завершения:

sudo smartctl -l selftest /dev/sda

Вывод содержит журнал самотестов с результатами. Запись «Completed without error» - норма. «Completed: read failure» с указанием LBA - обнаружен сбойный сектор. Запустите длинный тест для верификации и проверьте атрибуты Reallocated_Sector_Ct и Current_Pending_Sector.

Автоматизация еженедельных коротких и ежемесячных длинных тестов

Оптимальное расписание для production-серверов:

Короткий тест - еженедельно в нерабочее время.
Длинный тест - ежемесячно с разнесением по времени для разных дисков.

Конфигурация smartd для сервера с тремя дисками:

/dev/sda -a -o on -S on -s (S/../../6/02|L/../../1/03) -m admin@example.com
/dev/sdb -a -o on -S on -s (S/../../6/02|L/../../1/05) -m admin@example.com
/dev/sdc -a -o on -S on -s (S/../../6/02|L/../../1/07) -m admin@example.com

Расшифровка расписания: короткий тест по субботам в 02:00 для всех дисков одновременно (нагрузка минимальна), длинный тест в первое воскресенье месяца в 03:00, 05:00 и 07:00 для разных дисков. Разнесение длинных тестов предотвращает одновременную пиковую нагрузку на дисковую подсистему.

Результаты самотестов smartd включает в уведомления при использовании опции -a. Если тест завершился с ошибкой, вы получите письмо с указанием LBA сбойного сектора.

Для комплексного подхода к мониторингу дисковой подсистемы, включая отслеживание заполнения, температуры и интеграцию с мессенджерами, изучите руководство по автоматическому мониторингу дисков с уведомлениями в Telegram и email. Там разобраны готовые скрипты для smartd, Zabbix и Grafana.

Настроенный мониторинг S.M.A.R.T. с регулярными самотестами и оповещениями - это базовая гигиена серверной инфраструктуры. Затраты на внедрение: 15-20 минут на установку и конфигурацию. Результат: вы узнаете о проблемах с дисками за дни или недели до отказа, успеете сделать бэкап и заменить накопитель без аварийных работ и потери данных.