Средний ресурс потребительского HDD при круглосуточной работе составляет 3-5 лет, и первые признаки деградации появляются за месяцы до полного отказа. Диск не умирает мгновенно: растёт число переназначенных секторов, увеличивается время отклика, контроллер всё чаще повторяет операции. Без наблюдения за этими процессами администратор узнаёт о проблеме тогда, когда массив уже потерял один диск.
Мониторинг СХД строится вокруг четырёх групп метрик: здоровье накопителей (SMART), производительность (IOPS, latency, пропускная способность), ёмкость (свободное место, inode, снапшоты) и состояние пулов (RAID, ZFS, Ceph). Собирает их связка Prometheus, node_exporter и smartctl_exporter, показывает Grafana, а правила Alertmanager превращают графики в уведомления.
Минимальный набор, закрывающий большинство рисков: SMART-атрибуты 5, 187, 197, 198, 199, температура накопителей, свободное место на каждом разделе, статус пула и ошибки scrub. Этого хватает, чтобы получить несколько дней или недель на замену диска и не доводить массив до отказа второго накопителя.
Почему мониторинг СХД критичен для предотвращения сбоев
Отказ накопителя почти всегда растянут во времени. За несколько недель до выхода из строя диск начинает переназначать секторы из резервной области, и счётчик Reallocated_Sector_Ct растёт. Параллельно увеличивается latency: контроллер тратит время на повторные чтения. Пул при этом остаётся в статусе ONLINE, и без мониторинга изменений никто не замечает.
Опасность растёт с ёмкостью дисков. При вероятности невосстановимой ошибки чтения 1 на 10^14 бит восстановление RAID 5 из четырёх дисков по 8 ТБ требует прочитать около 24 ТБ данных, и шанс наткнуться на нечитаемый сектор приближается к 85%. Для enterprise-накопителей с показателем 10^15 бит риск падает примерно до 18%, но не исчезает. Если на момент отказа одного диска второй уже имеет pending-секторы, rebuild заканчивается ошибкой, и массив теряет данные.
В ZFS деградация проявляется иначе. Пул уходит в состояние DEGRADED при потере избыточности и в FAULTED или SUSPENDED, когда запись становится невозможной. Приложение в этот момент уже не работает, и время на реакцию измеряется часами, а не днями.
Реакция тоже занимает время: доставка диска со склада идёт 1-3 дня, resilver пула из четырёх дисков по 8 ТБ при активной нагрузке длится 10-20 часов. Алерт на SMART за сутки до отказа превращает аварийное восстановление в плановую замену. Алерт на свободное место за неделю до заполнения даёт возможность расширить пул без спешного удаления данных.
Ключевые метрики систем хранения: что и зачем отслеживать
Метрики СХД делятся на четыре группы, и каждая отвечает на свой вопрос: диск ещё живой, система успевает обслуживать запросы, места хватит на месяц, пул сохраняет избыточность. Ниже нормы и тревожные пороги по каждой группе.
SMART-показатели: какие атрибуты действительно важны
SMART отдаёт десятки атрибутов, но для решения о замене диска достаточно пяти-семи. Значения читаются командой smartctl -a /dev/sda. Для NVMe нужен ключ -d nvme, для дисков за RAID-контроллером -d megaraid,N, где N это номер устройства в контроллере.
- 5 Reallocated_Sector_Ct: сколько секторов диск переназначил из резервной области. Норма 0, любой устойчивый рост означает деградацию поверхности.
- 187 Reported_Uncorrect: ошибки, которые диск не смог исправить. Норма 0.
- 197 Current_Pending_Sector: секторы, которые пока читаются, но при записи требуют переназначения. Норма 0, значение выше нуля требует немедленной проверки.
- 198 Offline_Uncorrectable: ошибки, найденные во время автономных тестов. Норма 0.
- 199 UDMA_CRC_Error_Count: сбои на линии SATA. Диск здесь ни при чём, чаще виноват кабель или backplane, но растущее значение ломает производительность.
- 194 Temperature_Celsius: для HDD значения 45 °C и выше сокращают срок службы, 60 °C и выше критичны.
У SSD свои счётчики. 202 Percent_Lifetime_Remain показывает остаток ресурса в процентах, 241 Total_LBAs_Written считает записанный объём в LBA-блоках, у Intel это 177 Wear_Leveling_Count, у Kingston 231 SSD_Life_Left. Производители используют собственные номера атрибутов, поэтому перед выставлением порогов сверяйтесь с документацией на конкретную модель.
Для NVMe смотрите percentage_used, available_spare и media_errors в выводе nvme smart-log /dev/nvme0. Полезен и код возврата smartctl: битовая маска в конце вывода. Значение 8 означает провал SMART-порогов, и его удобно использовать в скриптах как готовый сигнал о замене.
Производительность: IOPS, latency и пропускная способность
Три метрики измеряют разное. IOPS это число операций ввода-вывода в секунду. Latency это время выполнения одной операции в миллисекундах, и она показывает, как быстро отвечает СХД. Пропускная способность это объём данных в секунду, важна для последовательных задач: бэкапов, копирования больших файлов, потоковой записи.
Базовые значения для ориентира. HDD 7200 rpm выдаёт 100-200 случайных IOPS при latency 5-15 мс. SATA SSD даёт 10 000-100 000 IOPS при latency 0,1-0,5 мс. NVMe показывает сотни тысяч IOPS и latency ниже 0,1 мс. Рост latency на HDD выше 20 мс при неизменной нагрузке сигнализирует о проблемах: переназначении секторов, фрагментации, ошибках контроллера, перегреве.
Команда iostat -x 1 даёт разбивку по устройствам. Смотрите на await (средняя latency с учётом очереди), r_await и w_await, aqu-sz (средняя длина очереди) и %util. С %util на NVMe и RAID-массивах нужно быть осторожным: устройства обрабатывают запросы параллельно, и 100% загрузки не означают насыщения. Ориентируйтесь на связку latency и длины очереди. Если aqu-sz растёт, а IOPS не увеличивается, упёрлись в предел накопителя или контроллера.
Свободное пространство и состояние пулов
Заполнение влияет не только на возможность записи, но и на скорость. В ZFS рабочий порог 80%: выше него растёт фрагментация, ускоряется износ, падает скорость записи и чтения. Под служебные нужды (slop space) ZFS резервирует около 3,2% объёма пула, а при заполнении 96% запись останавливается. Для ext4 актуален другой риск: 5% блоков по умолчанию зарезервированы под root, а при миллионах мелких файлов заканчиваются inode, и место на диске остаётся, писать при этом некуда.
Состояние пула проверяется по статусу. У ZFS это zpool status со значениями ONLINE, DEGRADED (потеряна избыточность), FAULTED (нет доступа к части устройств), SUSPENDED (часть записи не прошла). У программного RAID команда mdadm --detail /dev/md0 показывает State: clean, degraded или recovering. Состояние degraded означает, что массив жив, но второй отказ станет фатальным. Перестройка (rebuild или resilver) нагружает все диски, и в этот период latency вырастает в 2-5 раз.
Отдельно контролируйте расход снапшотов. В ZFS снапшоты держат блоки данных до удаления, и один снапшот трёхмесячной давности легко занимает половину пула. Метрика usedbysnapshots и её рост за неделю показывают проблему точнее, чем общий процент заполнения.
Инструменты мониторинга СХД: от встроенных средств до Prometheus и Grafana
Встроенные средства закрывают базовый уровень и не требуют установки дополнительных сервисов. smartd следит за SMART-атрибутами, шлёт письмо по адресу из /etc/smartd.conf и запускает короткие и длинные тесты по расписанию. ZED (ZFS Event Daemon) реагирует на события пулов, включая деградацию и ошибки checksum, и отправляет письма при заданном ZED_EMAIL_ADDR. TrueNAS показывает состояние дисков и пулов в веб-интерфейсе и оповещает о заполнении.
Для инфраструктуры из десятков узлов этого мало: уведомления расходятся по ящикам, история метрик не хранится, единой картины нет. Дальше выбор между Zabbix, Netdata и стеком Prometheus + Grafana. Zabbix удобен готовыми шаблонами по SNMP и автообнаружением дисков через LLD, Netdata даёт метрики с разрешением в секунду и запускается одной командой, Prometheus хранит временные ряды с нужной глубиной и одинаково работает и с одним сервером, и с кластером. Сравнение подходов с командами и конфигами разобрано в руководстве по мониторингу дискового пространства в Linux с Zabbix и Prometheus.
Для домашней лаборатории или трёх серверов хватает Netdata. С 10-20 узлов разумнее ставить Prometheus: pull-модель упрощает инвентаризацию, а единый источник метрик позволяет строить сквозные дашборды и алерты. Сам сервер мониторинга удобно разместить в облаке: Timeweb Cloud предоставляет VDS и хранилище для Prometheus, Grafana и Alertmanager, при этом нагрузка на боевые серверы ограничивается только экспортёрами.
Настройка сбора метрик СХД с помощью Prometheus и node_exporter
node_exporter отдаёт метрики ядра Linux по HTTP на порту 9100: загрузку CPU, память, сеть, операции с дисками и файловыми системами. SMART в него не входит, поэтому данные о здоровье накопителей собирают отдельно.
Установка и базовая конфигурация node_exporter
В Debian и Ubuntu пакет ставится командой apt install prometheus-node-exporter, в RHEL-совместимых дистрибутивах аналог доступен из репозитория. Если нужна свежая версия, бинарник распаковывают в /usr/local/bin, создают системного пользователя node_exporter и описывают unit для systemd.
[Unit] Description=Prometheus Node Exporter After=network-online.target [Service] User=node_exporter Group=node_exporter ExecStart=/usr/local/bin/node_exporter \ --collector.diskstats \ --collector.filesystem \ --collector.hwmon \ --collector.textfile.directory=/var/lib/node_exporter/textfile_collector \ --collector.filesystem.mount-points-exclude=^/(dev|proc|sys|run)($|/) Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target
Коллекторы diskstats и filesystem включены по умолчанию и дают метрики node_disk_reads_completed_total, node_disk_read_time_seconds_total, node_disk_io_time_seconds_total, node_filesystem_avail_bytes, node_filesystem_size_bytes и node_filesystem_files_free. Коллектор hwmon добавляет температуры с датчиков, filefd считает открытые дескрипторы. Каталог для textfile collector создают заранее: mkdir -p /var/lib/node_exporter/textfile_collector. Проверка после запуска: curl -s localhost:9100/metrics | grep node_disk. Пошаговая установка с разбором метрик CPU, памяти и дисков приведена в руководстве по мониторингу Linux-сервера с Node Exporter.
Сбор SMART-метрик через smartctl_exporter и textfile collector
Первый вариант это smartctl_exporter из состава сообщества Prometheus. Он опрашивает найденные диски, отдаёт метрики на порту 9633 и не требует своего формата записи. Второй вариант это скрипт, который пишет метрики в файл, а textfile collector подхватывает его при каждом scrape. Второй путь гибче: в один файл попадают SMART, состояние пулов ZFS, статус RAID и результаты scrub.
#!/usr/bin/env python3
import glob, json, os, subprocess
ATTRS = {
"Reallocated_Sector_Ct", "Current_Pending_Sector",
"Offline_Uncorrectable", "Reported_Uncorrect",
"Temperature_Celsius", "Percent_Lifetime_Remain",
}
lines = []
devices = sorted(glob.glob("/dev/sd?") + glob.glob("/dev/nvme?n?"))
for dev in devices:
try:
raw = subprocess.run(["smartctl", "-A", "-j", dev],
capture_output=True, text=True, timeout=30).stdout
data = json.loads(raw)
except Exception:
continue
disk = os.path.basename(dev)
for attr in data.get("ata_smart_attributes", {}).get("table", []):
if attr["name"] in ATTRS:
lines.append('smartctl_attr_raw{disk="%s",name="%s"} %s'
% (disk, attr["name"], attr["raw"]["value"]))
nvme = data.get("nvme_smart_health_information_log", {})
if "percentage_used" in nvme:
lines.append('smartctl_percent_used{disk="%s"} %s'
% (disk, nvme["percentage_used"]))
path = "/var/lib/node_exporter/textfile_collector/smart.prom"
tmp = path + ".tmp"
with open(tmp, "w") as fh:
fh.write("\n".join(lines) + "\n")
os.replace(tmp, path)
Скрипт запускается от root, поскольку smartctl требует доступа к устройству, и ставится в cron каждые 5 минут: */5 * * * * /usr/local/bin/smart_metrics.py. Запись через временный файл и os.replace нужна, чтобы textfile collector не прочитал половину данных. Если в файле появляются пустые значения, проверьте версию smartmontools: на старых сборках ключ -j не поддерживается, и парсинг придётся делать через awk по текстовому выводу.
Настройка Prometheus для сбора метрик с нескольких узлов
Prometheus описывает цели в prometheus.yml. Адреса перечисляются в static_configs, а роли размечаются метками, чтобы фильтровать запросы и алерты по группам серверов.
scrape_configs:
- job_name: node
scrape_interval: 30s
static_configs:
- targets: ['10.0.0.11:9100', '10.0.0.12:9100']
labels:
role: storage
env: prod
- job_name: smartctl
scrape_interval: 60s
static_configs:
- targets: ['10.0.0.11:9633', '10.0.0.12:9633']
labels:
role: storage
- job_name: nas
file_sd_configs:
- files:
- /etc/prometheus/targets/*.yml
Интервал 30 секунд для node_exporter достаточен и не создаёт лишней нагрузки, SMART обновляется раз в минуту, потому что атрибуты меняются медленно. Для парка больше 50 узлов статические списки заменяют на file_sd_configs или на обнаружение целей через Consul и Kubernetes API: файл со списком читается без перезапуска Prometheus. Отдельный job для NAS нужен, когда TrueNAS отдаёт метрики своим экспортёром или через SNMP.
Визуализация метрик СХД в Grafana: создание дашборда
Prometheus подключается в Grafana как источник данных типа Prometheus с адресом http://localhost:9090 и интервалом запроса, равным scrape_interval. Дальше собирается дашборд: строка на диски, строка на файловые системы, строка на пулы и алерты.
Ключевые панели для мониторинга СХД
Набор панелей, который закрывает диагностику СХД:
- Свободное место в процентах по каждому разделу с порогами 80/90/95 и цветовой индикацией. Визуализация: gauge или bar gauge.
- Прогноз заполнения на 7 и 30 дней, чтобы видеть дату исчерпания места, а не только текущий процент. Готовые прогнозы и уведомления в Telegram описаны в статье о мониторинге дисков и inode с Netdata и Grafana.
- Latency по дискам отдельными линиями с порогом 20 мс для HDD и 5 мс для SSD.
- IOPS и пропускная способность в двух режимах: суммарно по узлу и в разбивке по устройствам.
- Таблица SMART: имя диска, модель, значения атрибутов 5, 197, 198, температура. Цвет ячеек задаётся через value mappings, чтобы нули оставались зелёными, а любое значение выше нуля подсвечивалось красным.
- Статус пулов: для ZFS health как 0/1/2, для RAID состояния clean, degraded, recovering отдельными строками.
- Ошибки scrub и checksum: zfs_scan_errors_total или значение из zpool status.
Пример PromQL для ключевых метрик
Средняя latency чтения в миллисекундах:
rate(node_disk_read_time_seconds_total[5m]) / rate(node_disk_reads_completed_total[5m]) * 1000
Число операций чтения в секунду в разбивке по устройствам и узлам:
sum by (instance, device) (rate(node_disk_reads_completed_total[5m]))
Скорость записи в мегабайтах в секунду:
sum by (device) (rate(node_disk_written_bytes_total[5m])) / 1024 / 1024
Свободное место в процентах, только для реальных файловых систем:
node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"} / node_filesystem_size_bytes * 100
Прогноз свободного места через 7 дней по линейной экстраполяции за последние 6 часов:
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 7 * 86400) / 1024 / 1024 / 1024
SMART-атрибуты, температура и остаток ресурса SSD:
smartctl_attr_raw{name="Current_Pending_Sector"} > 0
smartctl_attr_raw{name="Temperature_Celsius"}
100 - smartctl_attr_raw{name="Percent_Lifetime_Remain"}
Для быстрого старта подойдут готовые дашборды для node_exporter, но их запросы опираются на конкретные имена устройств и метки. Свои панели собираются за вечер, а шаблон переменной $disk задаётся через label_values(node_disk_io_time_seconds_total, device), после чего фильтр по диску начинает работать во всех панелях сразу. Сложные запросы с несколькими агрегациями удобно черновиковать с помощью языковых моделей: AiTunnel даёт доступ к GPT, Gemini и Claude через один API с оплатой в рублях и без VPN, что ускоряет подбор PromQL и разбор правил алертов.
Настройка алертов на деградацию дисков и пулов
Алерты живут в Prometheus, уведомления отправляет Alertmanager. Правила описываются в отдельных файлах и подключаются через rule_files в prometheus.yml. Пороги ставят консервативно, а от срабатывания до действия оставляют запас по времени.
Правила алертов для SMART и состояния дисков
groups:
- name: storage-smart
rules:
- alert: DiskPendingSectors
expr: smartctl_attr_raw{name="Current_Pending_Sector"} > 0
for: 5m
labels:
severity: critical
annotations:
summary: Диск {{ $labels.disk }} имеет pending-секторы
description: Требуется smartctl -t long и подготовка замены
- alert: DiskReallocatedSectors
expr: increase(smartctl_attr_raw{name="Reallocated_Sector_Ct"}[24h]) > 0
for: 1h
labels:
severity: warning
- alert: DiskUncorrectable
expr: smartctl_attr_raw{name="Offline_Uncorrectable"} > 0
for: 5m
labels:
severity: critical
- alert: DiskTemperatureHigh
expr: smartctl_attr_raw{name="Temperature_Celsius"} > 55
for: 10m
labels:
severity: warning
- alert: SSDLifeLow
expr: smartctl_attr_raw{name="Percent_Lifetime_Remain"} < 10
for: 30m
labels:
severity: warning
Разница в логике важна. Reallocated_Sector_Ct смотрят по приросту за сутки, а не по абсолютному значению: диск с 20 переназначенными секторами, появившимися год назад, может работать ещё долго, а рост с 0 до 3 за сутки означает активную деградацию. Current_Pending_Sector, Offline_Uncorrectable и UDMA_CRC требуют реакции с нуля. Отдельное правило на рост UDMA_CRC_Error_Count ловит не смерть диска, а проблему с кабелем или backplane, и помогает не менять исправный накопитель.
Алерты на заполнение и деградацию пулов
Правила по ёмкости и пулам добавляются в тот же файл:
- alert: FilesystemAlmostFull
expr: node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.2
for: 30m
labels:
severity: warning
- alert: FilesystemCritical
expr: node_filesystem_avail_bytes / node_filesystem_size_bytes < 0.1
for: 15m
labels:
severity: critical
- alert: FilesystemWillFill
expr: predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}[6h], 3 * 86400) < 0
for: 1h
labels:
severity: warning
- alert: ZFSPoolDegraded
expr: zfs_pool_health < 2
for: 5m
labels:
severity: critical
- alert: ZFSPoolScrubErrors
expr: increase(zfs_pool_scrub_errors_total[7d]) > 0
for: 5m
labels:
severity: warning
- alert: RAIDArrayDegraded
expr: raid_state_degraded > 0
for: 5m
labels:
severity: critical
Метрики zfs_pool_health, zfs_pool_scrub_errors_total и raid_state_degraded не входят в node_exporter. Их добавляют тем же textfile collector: скрипт раз в минуту выполняет zpool status -x и mdadm --detail, переводит результат в числа и пишет в /var/lib/node_exporter/textfile_collector/pools.prom. Схема кодирования: для ZFS ONLINE = 0, DEGRADED = 1, остальные состояния = 2, чтобы условие zfs_pool_health < 2 точно ловило потерю избыточности. Для RAID clean = 0, degraded = 1, recovering = 2. Готовые сценарии с уведомлениями в Telegram и email для smartd, Zabbix и Grafana собраны в статье про автоматический мониторинг дисков с уведомлениями.
Настройка уведомлений в Alertmanager
route:
group_by: ['alertname', 'instance']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: telegram
receivers:
- name: telegram
telegram_configs:
- bot_token: 111111:AAA_BOT_TOKEN
chat_id: -1001234567890
parse_mode: HTML
- name: email
email_configs:
- to: storage-oncall@example.com
from: alertmanager@example.com
smarthost: smtp.example.com:587
require_tls: true
inhibit_rules:
- source_match:
severity: critical
target_match:
severity: warning
equal: ['instance']
Параметр group_by собирает алерты по одному диску в одно сообщение, а inhibit_rules глушит предупреждения, когда по тому же узлу уже пришёл критический алерт. Значение repeat_interval 4 часа не даёт уведомлениям превратиться в спам по деградировавшему диску, который ждёт замены. Перед выводом в прод правила проверяют командой promtool check rules и тестовым срабатыванием: порог временно снижают, чтобы убедиться, что сообщение доходит до дежурного.
Интерпретация метрик и реакция на инциденты
Без baseline любой график бесполезен. Соберите метрики за одну-две недели и зафиксируйте нормальные значения: latency в рабочие часы, ночные пики от бэкапов, еженедельный scrub, который добавляет нагрузку на 2-6 часов. После этого отклонения читаются сразу: разовый скачок latency при копировании большого файла нормален, устойчивый рост средней latency на 30-50% при неизменной нагрузке уже нет.
Порядок действий при срабатывании алертов:
- Pending-секторы или uncorrectable-ошибки: запустить smartctl -t long, затем smartctl -a и принять решение о замене. Если диск входит в пул с избыточностью, замену планируют, а не откладывают до отказа.
- Рост переназначенных секторов: заказать диск, проверить бэкапы, отслеживать значение каждые 15 минут.
- Ошибки checksum в ZFS: zpool status -v покажет список повреждённых файлов, а zpool clear сбрасывает счётчик после устранения причины. Регулярный zpool scrub раз в месяц выявляет такие ошибки до того, как о них сообщит приложение.
- Degraded RAID: заменить диск, дождаться завершения rebuild и не запускать scrub или тяжёлые задачи во время перестройки.
- Заполнение выше 90%: удалить устаревшие снапшоты, перенести данные, добавить vdev или расширить массив дисками того же размера.
- Рост latency сразу на всех дисках узла: проверять HBA, кабели, прошивку контроллера и температуру в корпусе, а не накопители по одному.
Отдельный сценарий это ложные срабатывания. На виртуальных машинах метрики дисков приходят от гипервизора, и latency зависит от соседей по хранилищу, поэтому пороги для VM и физических серверов разные. Алерт на температуру для дисков в серверной с плохой вентиляцией будет срабатывать каждое лето, и порог корректируют по факту, а не отключают правило.
Особенности мониторинга СХД в виртуализации и Kubernetes
В распределённых системах к общим метрикам добавляются метрики уровня хранилища. Ceph отдаёт состояние кластера через модуль mgr prometheus на порту 9283: ceph_health_status, ceph_osd_up, ceph_pool_used_bytes, число деградировавших объектов pg_degraded. Для Ceph критичны три показателя: здоровье кластера, число живых OSD и заполнение пулов, потому что при 85% и выше кластер начинает отказывать в записи.
Proxmox показывает состояние ZFS и LVM в веб-интерфейсе, отдельные метрики снимаются экспортёром pve-exporter или обычным node_exporter на каждом узле. В Kubernetes состояние томов приходит из kubelet: метрики kubelet_volume_stats_available_bytes, kubelet_volume_stats_used_bytes и kubelet_volume_stats_capacity_bytes дают заполнение PVC, а node_exporter в составе DaemonSet закрывает метрики дисков узлов. Для Rook-Ceph и других CSI-драйверов добавляют метрики самого драйвера. Общий подход не меняется: Prometheus, Grafana и Alertmanager остаются, к ним подключаются дополнительные экспортёры. Готовые дашборды для кластерных решений с Pacemaker и Ceph собраны в статье про мониторинг кластеров серверов.
Чек-лист внедрения мониторинга СХД
- Составить инвентарь: список дисков, моделей, пулов, разделов и их назначения.
- Установить node_exporter на все узлы с СХД и включить коллекторы diskstats, filesystem, hwmon и textfile.
- Развернуть smartctl_exporter или скрипт сбора SMART-метрик и настроить запуск по cron каждые 5 минут.
- Добавить в textfile collector метрики пулов ZFS и состояния RAID.
- Описать jobs в prometheus.yml, разметить узлы метками role и env, задать ретенцию данных не менее 30 дней.
- Собрать дашборд Grafana: место, latency, IOPS, таблица SMART, статус пулов.
- Написать правила алертов на SMART, заполнение, прогноз заполнения и деградацию пулов, проверить их через promtool.
- Настроить Alertmanager: Telegram или email, группировку, подавление дублей, тестовое срабатывание.
- Собрать baseline за одну-две недели и скорректировать пороги под свою нагрузку.
- Задокументировать пороги и порядок реакции, назначить ответственного за инциденты.
- Поставить расписание zpool scrub раз в месяц и длинных SMART-тестов раз в неделю.
- Проверить, что бэкапы снимаются и восстанавливаются: мониторинг предупреждает о риске, но не заменяет резервные копии.
Начните с двух алертов: Current_Pending_Sector больше нуля и свободное место меньше 20%. Эти правила требуют минимум настройки и закрывают самые частые причины потери данных, а остальные метрики добавляются по мере роста инфраструктуры.