Мониторинг и диагностика СХОД: метрики, логи и алерты для дисков, RAID и производительности

Отказ диска в массиве из двенадцати накопителей почти никогда не начинается внезапно. За несколько дней до сбоя растёт число pending-секторов, чуть позже увеличивается задержка записи на конкретном устройстве, и только потом контроллер помечает накопитель как failed. Мониторинг СХОД нужен, чтобы поймать первые два сигнала и заменить диск в плановом окне, а не в режиме аварии.

Минимальный набор для старта: SMART-состояние дисков, состояние RAID или ZFS-пула, доступность и latency томов, свободное место, ошибки в логах ядра. Базовый стек выглядит так: node_exporter, smartctl_exporter, Prometheus, Alertmanager, Grafana. Zabbix закрывает те же задачи в агентной модели и часто уже развёрнут в компании, поэтому его разумно оставить для базовых триггеров и инвентаря, а Prometheus с Grafana добавить там, где нужны гибкие запросы и длинные тренды.

Что мониторить в СХОД в первую очередь: минимальный рабочий набор

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

Четыре слоя СХОД и что ломается на каждом

Показательный случай: массив в статусе healthy, RAID не degraded, но latency тома выросла вдвое. Причина обычно в одном диске, который перемалывает бэд-блоки и отвечает в разы медленнее остальных. Увидеть это можно только на слое устройства, сопоставив node_disk_read_time_seconds_total и node_disk_write_time_seconds_total по конкретному диску, а не по всему массиву.

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

Минимальный стек: Prometheus, exporters, Grafana, Alertmanager

• node_exporter отдаёт метрики ОС и дисков: время операций, объём чтения и записи, свободное место, состояние файловых систем.
• smartctl_exporter читает атрибуты через smartctl и публикует их в формате Prometheus.
• Prometheus опрашивает экспортеры по pull-модели и хранит временные ряды.
• Alertmanager группирует уведомления, маршрутизирует их по severity и подавляет дубли.
• Grafana визуализирует ряды и держит дашборды дежурного.

Развёртывание в контейнерах занимает один файл:

services:
  prometheus:
    image: prom/prometheus:v2.53.0
  node_exporter:
    image: prom/node-exporter:v1.8.1
    pid: host
    volumes: ['/:/host:ro,rslave']
    command: ['--path.rootfs=/host']
  smartctl_exporter:
    image: prometheuscommunity/smartctl-exporter:v0.12.0
    privileged: true
    command: ['--smartctl.device=/dev/sda', '--smartctl.device=/dev/sdb']
  alertmanager:
    image: prom/alertmanager:v0.27.0
  grafana:
    image: grafana/grafana:11.1.0

Без контейнеров те же компоненты ставятся пакетами и стартуют юнитами systemd: prometheus.service, node_exporter.service, alertmanager.service, grafana-server.service. Для SMART достаточно одного юнита smartctl_exporter с флагом --smartctl.device на каждый накопитель.

Сбор данных описывается в prometheus.yml, где частота опроса SMART задаётся отдельно от остальных метрик:

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['storage-01:9100']
  - job_name: smartctl
    scrape_interval: 5m
    static_configs:
      - targets: ['storage-01:9633']

Метрики дисков и SMART: какие атрибуты реально предсказывают отказ

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

Список атрибутов, порогов и готовые конфиги для Prometheus, node_exporter и smartctl_exporter собраны в руководстве по мониторингу систем хранения, здесь разберём логику выбора порогов.

Проверить состояние вручную можно двумя командами: smartctl -H /dev/sdX показывает итоговый вердикт, smartctl -a /dev/sdX выводит полную таблицу атрибутов с RAW-значениями. Запускать их на работающем диске безопасно, это чтение регистров, а не тест.

SMART для HDD и SSD: разные пороги, разные риски

Для HDD ключевые сигналы связаны с поверхностью: Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable. Механика деградирует постепенно, и рост переназначенных секторов от 0 до 50 за месяц означает, что диск доживает последние недели.

Для SATA SSD логика другая. Смотреть нужно на Percentage_Used: значение выше 80% означает, что ресурс перезаписи почти исчерпан и замену пора планировать. Атрибуты Available_Spare и Media_Errors показывают, сколько резервных блоков осталось и появлялись ли неисправимые ошибки. Ненулевое Media_Errors на SSD - критичный сигнал, даже если массив продолжает работать.

NVMe-накопители SMART через smartctl отдают неполно, для них используется nvme smart-log /dev/nvme0: там важны Percentage_Used, Available_Spare, Media_Errors и Critical_Warning. Резкое падение Available_Spare за короткий срок говорит о деградации массива NAND, и такой диск меняют до того, как он перейдёт в read-only.

Как подключить smartctl_exporter и не сломать диски

Опрос SMART раз в 5-15 минут безопасен и не мешает работе диска. Нагрузку создаёт не чтение атрибутов, а тесты: smartctl -t long или -t short гоняют головки по всей поверхности и на продакшене запускаются только в окне обслуживания. Экспортеру тесты не нужны.

Отдельный случай - аппаратные RAID-контроллеры LSI и Broadcom. За ними SMART напрямую недоступен, поэтому состояние дисков снимают через storcli или megacli, а результат передают в Prometheus через textfile collector либо специализированный экспортер. События контроллера смотрят командой storcli /c0 show events, там видны ошибки линка и отвалы дисков, которых не показывает ни один SMART-атрибут.

Ещё одна деталь: вендоры кодируют RAW-значения по-разному. У части моделей Seagate атрибут Raw_Read_Error_Rate выглядит как огромное число и при этом не означает проблему. Пороги калибруют на своей парке дисков, иначе алерты превратятся в постоянный шум.

RAID и ZFS: метрики состояния массива и алерты на деградацию

Деградация массива - инцидент с обратным отсчётом. Пока идёт rebuild, любой второй отказ приводит к потере данных, поэтому алерт на degraded должен срабатывать за минуту, а не за час.

mdadm: что смотреть и как алертить

Быстрая проверка состояния программного RAID: cat /proc/mdstat и mdadm --detail /dev/md0. Первая команда показывает статус и прогресс синхронизации, вторая - список устройств, их роль и число сбойных.

В мониторинг выносят три метрики: статус массива (active или degraded), количество failed devices и прогресс resync. Универсальное правило: md_degraded больше нуля - critical. Значение 0 при активном rebuild тоже требует внимания: скорость синхронизации оценивают отдельной панелью, и если она упала до нескольких мегабайт в секунду, значит, нагрузка на массив слишком высокая и rebuild не закончится в разумное время.

После замены диска важно не терять контроль: повторная деградация во время rebuild означает, что нужно остановить нагрузку на массив и снизить приоритет синхронизации командой mdadm --detail с последующей корректировкой speed_limit_max.

ZFS: пулы, scrub, resilver и ошибки контрольных сумм

ZFS сам считает и хранит статистику ошибок, остаётся её забрать. Базовые команды: zpool status -v показывает состояние пула и список файлов с ошибками, zpool list -v выводит состав vdev и использование дисков, zfs list -o space даёт детализацию по датасетам с учётом reservation и quota.

Ключевые метрики для алертов:

• zpool_state: ONLINE, DEGRADED, FAULTED. Любое значение кроме ONLINE - critical с задержкой в минуту.
• zpool_errors_read, zpool_errors_write, zpool_errors_cksum: ненулевые cksum-ошибки - warning, они указывают на проблемы с диском, кабелем или памятью без ECC.
• zpool_resilver_progress и время до завершения: нужны, чтобы понимать окно уязвимости.
• zpool_scrub_errors: рост ошибок между scrub-запусками означает, что пул молча теряет целостность.

Единичные ошибки контрольных сумм ZFS исправляет сама, поэтому паниковать из-за одной записи не стоит. Тревожно другое: рост cksum-ошибок от scrub к scrub. Если к одной и той же ошибке привязан один диск, меняют диск; если ошибки распределены по разным устройствам, проверяют контроллер, кабели и оперативную память. Для разбора инцидента помогает zpool events, она хранит хронологию событий пула с метками времени.

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

Производительность СХОД: latency, IOPS, throughput и поиск узких мест

Три метрики описывают почти любую проблему производительности. Latency показывает, сколько ждёт одна операция. IOPS показывает, сколько операций в секунду выполняет система. Throughput показывает, сколько байт в секунду проходит через интерфейс. Разные сочетания этих значений указывают на разные причины.

В node_exporter данные лежат в счётчиках: node_disk_read_bytes_total, node_disk_write_bytes_total, node_disk_reads_completed_total, node_disk_writes_completed_total, node_disk_read_time_seconds_total, node_disk_write_time_seconds_total, node_disk_io_time_seconds_total. Средняя задержка считается как отношение времени операций к их количеству:

(rate(node_disk_read_time_seconds_total[5m]) + rate(node_disk_write_time_seconds_total[5m]))
/ (rate(node_disk_reads_completed_total[5m]) + rate(node_disk_writes_completed_total[5m]))

Ориентиры для алертов: HDD с latency выше 20 мс работает на пределе, SSD выше 5 мс, NVMe выше 1 мс. Пороги стоит поднимать для массивов с тяжёлой записью и опускать для latency-чувствительных баз данных.

iostat и node_exporter: как читать метрики вместе

Привычный iostat -x 1 сопоставляется с метриками Prometheus почти один к одному. Поле await примерно соответствует средней latency, %util близко к node_disk_io_time_seconds_total, aqu-sz отражает глубину очереди. Полезно снимать базовую линию на здоровой системе: iostat -x 1 5 в час пик даёт нормальные значения для конкретной нагрузки.

Комбинации значений читаются так:

• await растёт и %util близок к 100%: диск перегружен, узкое место на устройстве.
• await растёт, а %util низкий: проблема в очереди, контроллере или кабеле, а не в самом носителе.
• IOPS высокие, throughput низкий: работа идёт мелкими блоками, часто это следствие неоптимального размера ввода-вывода в приложении.
• На диске всё в норме, приложение тормозит: смотреть сеть, файловую систему и блокировки на уровне СУБД.

У %util есть подвох на NVMe: несколько параллельных очередей обрабатываются одновременно, поэтому 100% на графике не означают насыщение. На быстрых накопителях надёжнее опираться на latency и глубину очереди. Как отделить проблему хранилища от деградации CPU, памяти или сети, разобрано в материале про метрики производительности сервера в Linux.

fio для проверки гипотез и валидации порогов

График показал рост latency, но причин может быть две: деградация железа или изменившийся профиль нагрузки. Различить их помогает fio, запущенный на свободном участке тома:

fio --name=randread --ioengine=libaio --direct=1 --rw=randread \
  --bs=4k --iodepth=32 --numjobs=4 --size=8G --runtime=300 \
  --group_reporting --filename=/mnt/data/fio.test

Результат сравнивают с историческим бенчмарком той же команды. Если случайное чтение блоками 4 КБ упало с 45 000 до 12 000 IOPS при том же профиле, диск или кэш контроллера деградировали. Если цифры совпадают, а приложение тормозит, искать причину нужно выше по стеку.

Запускать fio на продакшене без окна нельзя: параметр --direct=1 обходит кэш и создаёт реальную нагрузку на носители. Для экспериментов удобно подготовить отдельный стенд, например поднять тестовый сервер с нужным типом диска в облаке, чтобы не рисковать рабочим массивом: Timeweb Cloud даёт серверы и дисковые тома с почасовой оплатой, что удобно для калибровки порогов алертов под конкретное железо. Результаты замеров напрямую влияют на то, какие значения latency считать аномалией.

Логи СХОД: что смотреть при деградации и как централизовать

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

Ключевые паттерны в логах, которые предсказывают отказ

Источники: вывод dmesg, journalctl -k, файлы /var/log/syslog и /var/log/messages, события ZFS через zpool events, журнал контроллера через storcli /c0 show events.

Читать journalctl -k целиком бессмысленно, вывод быстро переполняется. Полезнее фильтр по времени: journalctl -k --since '2 hours ago' и поиск по ключевым словам. Алерт на лог-паттерн настраивают так же, как на метрику: важна не единичная строка, а повторение за окно.

Централизация логов: Promtail + Loki vs rsyslog

Promtail вместе с Loki даёт лёгкий сбор и удобную связку с Grafana: логи фильтруются по меткам, а алерты по ним строятся через Loki Ruler или через Alertmanager. Конфигурация для системного журнала занимает несколько строк:

scrape_configs:
  - job_name: syslog
    static_configs:
      - targets: [localhost]
        labels:
          job: syslog
          __path__: /var/log/syslog

Связка rsyslog с Elasticsearch тяжелее в обслуживании, зато даёт мощный полнотекстовый поиск и привычна командам, которые давно работают с ELK. Выбор зависит от масштаба: до сотни серверов Loki закрывает задачу с меньшими ресурсами, в крупной инфраструктуре с готовым кластером Elasticsearch разумнее не плодить второй стек.

Когда нужно быстро разобрать несколько тысяч строк после инцидента, выгрузку удобно прогнать через модель и получить краткую сводку по времени и устройствам, например через AiTunnel, где доступ к разным моделям идёт через один API. Такой разбор экономит время при подготовке postmortem, но не заменяет ручную проверку выводов.

Алерты без шума: правила, пороги и маршрутизация в Alertmanager и Zabbix

Хороший алерт отвечает на три вопроса: что случилось, чем это грозит и что делать. Если ответить нельзя, уведомление лучше не отправлять. Второе правило: у каждого алерта есть severity, задержка for и ссылка на runbook в описании.

Примеры правил для Prometheus Alertmanager

Правила хранятся отдельным файлом и подключаются в prometheus.yml через rule_files. Перед выкладкой их проверяют командой promtool check rules.

groups:
  - name: storage
    rules:
      - alert: DiskPendingSectors
        expr: smartctl_device_attribute{attribute_name="Current_Pending_Sector"} > 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: 'Нестабильные сектора на {{ $labels.device }}'
      - alert: RaidDegraded
        expr: md_degraded > 0
        for: 1m
        labels:
          severity: critical
      - alert: ZfsPoolNotOnline
        expr: zpool_state != 1
        for: 1m
        labels:
          severity: critical
      - alert: VolumeLatencyHigh
        expr: (rate(node_disk_read_time_seconds_total[10m]) + rate(node_disk_write_time_seconds_total[10m])) / (rate(node_disk_reads_completed_total[10m]) + rate(node_disk_writes_completed_total[10m])) > 0.02
        for: 15m
        labels:
          severity: warning

Задержка for убирает одиночные всплески. Для метрик, которые колеблются от нагрузки, вместо мгновенного значения берут avg_over_time или rate с окном в 10-15 минут. Нулевая задержка оправдана только для FAULTED-состояния пула и недоступности узла.

В Alertmanager настраивают группировку и подавление. Классический пример: если узел недоступен, алерты по его дискам и пулам отправлять не нужно.

inhibit_rules:
  - source_matchers: [severity="critical", alertname="NodeDown"]
    target_matchers: [severity=~"warning|critical"]
    equal: [instance]

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

Zabbix: триггеры, зависимости и эскалации

В Zabbix тот же уровень контроля собирается из элементов данных и триггеров. SMART-атрибуты забираются через UserParameter в агенте или Zabbix agent 2, значения хранятся как числовые элементы, триггеры сравнивают их с порогами. Удобно, что вендорские шаблоны для популярных RAID-контроллеров и дисков уже готовы, и старт занимает меньше времени, чем настройка экспортеров с нуля.

Обязательный приём для Zabbix - зависимости триггеров. Триггер на диск зависит от триггера доступности узла, поэтому при падении сервера приходит одно уведомление, а не пятьдесят. Эскалация настраивается по шагам: первое сообщение в мессенджер, через 15 минут без подтверждения - звонок ответственному, через час - руководителю смены.

Дашборды Grafana и Zabbix: что должно быть на экране дежурного

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

Панели для дисков и RAID: примеры запросов

Структура, которая работает на практике:

1. Верхний ряд: общий статус. Все пулы ONLINE, ни один RAID не degraded, нет критичных алертов. Сюда же имеет смысл вывести SLO: доля времени за неделю, когда пул был ONLINE и latency оставалась ниже порога.
2. Второй ряд: диски. SMART-статус, температура, число pending-секторов, для SSD - Percentage_Used.
3. Третий ряд: производительность. Latency, IOPS и пропускная способность по томам и дискам.
4. Четвёртый ряд: ёмкость. Свободное место и прогноз заполнения.
5. Пятый ряд: события из логов и алерты за последние сутки.

Готовые PromQL-запросы для панелей:

smartctl_device_smart_status == 0
smartctl_device_attribute{attribute_name="Temperature_Celsius"} > 50
md_degraded > 0
zpool_state != 1

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

Прогноз заполнения ёмкости и capacity planning

Место заканчивается предсказуемо, и предупредить об этом можно заранее. В Prometheus есть функция линейной экстраполяции по последним данным:

predict_linear(node_filesystem_avail_bytes{mountpoint="/data"}[7d], 30*24*3600)
  < 0.1 * node_filesystem_size_bytes{mountpoint="/data"}

Правило срабатывает, когда через 30 дней свободного места останется меньше 10%. Для ZFS расчёт сложнее из-за reservation и quota, поэтому к графику добавляют вывод zfs list -o space: там видно реальное потребление датасетов, включая снапшоты, которые часто и съедают место.

Прогноз по тренду - основа capacity planning: он превращает закупку дисков из аварийной задачи в плановую и позволяет заранее посчитать, хватит ли слотов в шасси. Методика расчёта требований по IOPS, латентности и объёму с запасом на рост описана в методике выбора системы хранения.

Предупреждение сбоев: как встроить мониторинг в процессы эксплуатации

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

Runbook для типовых инцидентов СХОД

Каждый алерт ссылается на короткую инструкцию. Примеры:

• DiskPendingSectors. Проверить smartctl -a /dev/sdX, сравнить RAW-значения с историей за месяц, заказать диск, заменить в ближайшее окно, после замены следить за прогрессом rebuild через cat /proc/mdstat.
• RaidDegraded. Убедиться, что массив не потерял второй диск, снять резервную копию важных данных, заменить накопитель, ограничить скорость синхронизации в часы пик.
• ZfsPoolNotOnline. Собрать zpool status -v и zpool events, не запускать scrub до выяснения причины, при FAULTED сначала сохранить данные.
• VolumeLatencyHigh. Сопоставить latency по дискам, проверить очередь, исключить фоновые задачи и rebuild, при подтверждении деградации диска действовать по первому сценарию.

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

Проверка бэкапов и восстановление как часть мониторинга

Наличие копии без проверки восстановления даёт ложное чувство защиты. В мониторинг добавляют три вещи: алерт, если последний успешный бэкап старше 24 часов; контроль ошибок в заданиях резервного копирования; регулярное тестовое восстановление, например раз в квартал на отдельном стенде.

Для бэкап-пулов на ZFS полезно запускать scrub по расписанию и следить за cksum-ошибками: они показывают, что копия уже повреждена и восстановление из неё не сработает. Прошивки дисков и контроллеров обновляют по вендорским release notes, перед работой снимая дамп конфигурации контроллера и проверяя, что массив не в состоянии rebuild.

Плановая замена по трендам закрывает основную часть рисков: если Reallocated_Sector_Ct растёт два месяца подряд, диск меняют до того, как он выпадет из массива. Мониторинг здесь работает не как система тревог, а как источник данных для планирования.

Prometheus или Zabbix: как выбрать и не переделывать через полгода

Оба инструмента решают задачу, разница в модели работы и пороге входа.

Для СХОД важнее не инструмент, а покрытие метрик и качество правил. Гибрид встречается чаще монолита: Zabbix ведёт инвентарь, доступность и базовые триггеры, а Prometheus с Grafana отвечают за глубокие запросы, тренды и прогнозы. Такой вариант не требует миграции и позволяет наращивать глубину постепенно.

Если решать приходится с нуля, отталкивайтесь от навыков команды и текущей инфраструктуры. В компании, где Zabbix уже стоит и знаком дежурным, разумнее расширить его шаблонами и добавить Grafana как источник дашбордов, чем строить второй стек с нуля. В среде с контейнерами и Kubernetes выбор в пользу Prometheus почти очевиден: экспортеры и service discovery там работают из коробки.

Начните с малого: включите алерт на Current_Pending_Sector, триггер на degraded RAID и правило на состояние ZFS-пула. Эти три правила закрывают большинство сценариев, которые приводят к потере данных, и дают время спокойно достроить остальную наблюдаемость.