Интеграция систем учета хранения с системами мониторинга: настройка экспортеров, дашбордов и алертов

Метрики хранилища попадают в Zabbix, Prometheus и Grafana тремя основными путями: SNMP, REST API самой СХД и локальные экспортеры на хосте, который видит тома. Выбор пути определяет и полноту данных, и время на настройку. Для Zabbix проще всего SNMP или агент, для Prometheus - экспортеры с textfile collector, для современных NAS с API - собственный сборщик на Python или Go.

Ниже разобраны рабочие конфигурации: включение SNMP и проверка OID, установка node_exporter и snmp_exporter, скрипт сбора метрик ZFS, сборка дашборда Grafana с прогнозом заполнения, правила алертов в Zabbix и Prometheus с отправкой в Telegram и Slack. Все примеры рассчитаны на Linux-серверы с локальными, NFS и iSCSI томами, а также на устройства с SNMP-агентом.

Начните с двух вещей: определите, какие метрики критичны именно для вашего парка (заполнение томов, состояние пулов, температура, ошибки дисков), и проверьте, какой интерфейс отдаёт эти данные. Дальше настройка сводится к трём шагам - сбор, визуализация, уведомления.

Зачем интегрировать СХД с системами мониторинга

Том на 2 ТБ при приросте 55 ГБ в сутки заполняется за 37 дней. Без мониторинга об этом узнают в момент, когда СУБД уходит в read-only, а сервис начинает отдавать ошибки. Место заканчивается тихо и предсказуемо, поэтому контроль заполнения даёт самый дешёвый выигрыш по времени реакции.

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

Интеграция закрывает три задачи: непрерывный сбор метрик заполнения и производительности, визуализация трендов для планирования ёмкости, автоматические уведомления о критических событиях. Обзор метрик с разбором SMART, latency и состояния пулов собран в материале мониторинг систем хранения: ключевые метрики и инструменты для администратора.

Выбор метода сбора метрик с СХД

Четыре способа покрывают практически весь парк оборудования.

Практическое правило: в Zabbix берите SNMP или агент, в Prometheus - экспортеры. Смешивать подходы стоит только тогда, когда часть парка составляют старые СХД без API.

SNMP для Zabbix: плюсы и минусы

SNMP работает на любом железе, включая RAID-контроллеры и ИБП, но опрос идёт последовательно и на слабых контроллерах растягивается. Версия v3 добавляет шифрование и аутентификацию, v2c ограничивается строкой community, которая передаётся открытым текстом.

Включите SNMP на СХД, заведите пользователя только для чтения и ограничьте доступ по IP сервера Zabbix. Перед созданием хоста проверьте, что нужные OID отдают данные.

snmpwalk -v3 -l authPriv -u monitor -a SHA -A 'passphrase' -x AES -X 'passphrase' 192.168.1.20 .1.3.6.1.2.1.25.2.3.1

Ключевые OID из HOST-RESOURCES-MIB: .1.3.6.1.2.1.25.2.3.1.5 (hrStorageSize), .1.3.6.1.2.1.25.2.3.1.6 (hrStorageUsed) и .1.3.6.1.2.1.25.2.3.1.4 (hrStorageAllocationUnits). Занятое место считается как hrStorageUsed, умноженный на hrStorageAllocationUnits, и результат обязательно сверяется с выводом df на самой СХД.

В Zabbix создайте хост с интерфейсом SNMP на порту 161, задайте макрос {$SNMP_COMMUNITY} и привяжите шаблон SNMP Storage или Network Generic Device by SNMP. Тома обнаруживаются через LLD по индексам таблицы. Проверенные связки Zabbix с дисками и разбор альтернатив описаны в статье про мониторинг дискового пространства в Linux.

Минусы SNMP заметны сразу: температура и SMART-атрибуты часто доступны только через приватные OID вендора, а интервал опроса короче 60 секунд нагружает контроллер. TrueNAS по SNMP отдаёт базовый набор по UCD-SNMP-MIB, глубокие данные о ZFS лучше брать локально или через API.

Экспортеры для Prometheus: node_exporter и snmp_exporter

node_exporter ставится на хост, который видит тома, и отдаёт метрики по адресу /metrics. Для нестандартных данных включается textfile collector.

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

Проверка, что метрики файловых систем отдаются:

curl -s http://localhost:9100/metrics | grep node_filesystem_avail_bytes

Для SNMP-устройств применяется snmp_exporter. Его конфиг генерируется из MIB-файлов, поэтому набор OID не нужно прописывать руками.

docker run --rm -v "$PWD:/opt" -w /opt prom/snmp-generator generate

В prometheus.yml описывается отдельный job, который проксирует запросы к snmp_exporter через relabeling.

- job_name: storage_snmp
  metrics_path: /snmp
  params:
    module: [if_mib]
  static_configs:
    - targets:
        - 192.168.1.20
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: instance
    - target_label: __address__
      replacement: 127.0.0.1:9116

TrueNAS отдаёт метрики собственным экспортером и через REST API с ключом доступа. Если готового экспортера нет, промежуточный скрипт забирает JSON и записывает значения в .prom файл для textfile collector.

Если вы разворачиваете Prometheus, Alertmanager и экспортеры с нуля, удобно взять готовую площадку: Timeweb Cloud даёт серверы, VDS/VPS, базы данных и хранилище с гибким изменением ресурсов под нагрузку сбора метрик.

Настройка экспортеров метрик хранилища

Сбор метрик с ZFS через node_exporter

Скрипт /usr/local/bin/zfs_metrics.sh формирует файл метрик атомарно, чтобы Prometheus не прочитал половину строки.

#!/bin/bash
OUT=/var/lib/node_exporter/textfile
TMP=$(mktemp)
{
  echo "# HELP zpool_size_bytes Total pool size in bytes"
  echo "# TYPE zpool_size_bytes gauge"
  echo "# HELP zpool_alloc_bytes Allocated bytes in pool"
  echo "# TYPE zpool_alloc_bytes gauge"
  echo "# HELP zpool_health Pool health state"
  echo "# TYPE zpool_health gauge"
  zpool list -Hp -o name,size,alloc,free,health | while read -r name size alloc free health; do
    printf 'zpool_size_bytes{pool="%s"} %s\n' "$name" "$size"
    printf 'zpool_alloc_bytes{pool="%s"} %s\n' "$name" "$alloc"
    printf 'zpool_free_bytes{pool="%s"} %s\n' "$name" "$free"
    if [ "$health" = "ONLINE" ]; then
      printf 'zpool_health{pool="%s"} 1\n' "$name"
    else
      printf 'zpool_health{pool="%s"} 0\n' "$name"
    fi
  done
} > "$TMP"
mv "$TMP" "$OUT/zfs.prom"

Флаг -p в zpool list выдаёт размеры в байтах, поэтому пересчёт из гигабайтов не нужен и ошибка округления не накапливается. Запуск раз в минуту через cron или systemd timer.

*/1 * * * * /usr/local/bin/zfs_metrics.sh

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

for d in /dev/sd?; do
  t=$(smartctl -A "$d" | awk '/Temperature_Celsius/ {print $10; exit}')
  [ -n "$t" ] && printf 'disk_temperature_celsius{device="%s"} %s\n' "${d##*/}" "$t"
done > /var/lib/node_exporter/textfile/smart.prom

Готовый zfs_exporter в контейнере тоже подходит, но textfile collector требует меньше зависимостей и работает на хосте без Docker. Имя файла обязательно должно оканчиваться на .prom, иначе node_exporter его игнорирует.

Настройка Zabbix агента для мониторинга томов

Кастомные метрики задаются через UserParameter в /etc/zabbix/zabbix_agentd.d/storage.conf.

UserParameter=storage.used[*],df -P "$1" | awk 'NR==2 {gsub(/%/,""); print $5}'
UserParameter=storage.free[*],df -P -B1 "$1" | awk 'NR==2 {print $4}'
UserParameter=zpool.health[*],zpool list -H -o health "$1" 2>/dev/null || echo UNKNOWN

Агенту нужны права на запуск zpool: добавьте пользователя zabbix в группу с доступом к /dev/zfs. Проверка ключа с сервера Zabbix:

zabbix_get -s 192.168.1.10 -k 'storage.used[/data]'

Встроенные ключи vfs.fs.size[/data,pused], vfs.fs.size[/data,free] и vfs.fs.size[/data,total] закрывают заполнение без UserParameter, но состояние пулов ZFS и RAID-массивов они не показывают. Триггер на заполнение выше 90% выглядит так:

{Template Storage:storage.used[/data].last()}>90

Создание дашбордов Grafana для хранилища

В Grafana подключаются два источника данных: Prometheus для метрик экспортеров и Zabbix через плагин для того, что уже собирается агентом. Панели собираются из запросов PromQL или из вызовов Zabbix API, интервал дискретизации для СХД разумно держать на 60 секундах - чаще нет смысла, контроллер не отдаёт данные быстрее.

Если сложный PromQL нужно собрать быстро, запрос можно сгенерировать через LLM: AiTunnel даёт доступ к GPT, Gemini и Claude через единый интерфейс с оплатой в рублях и управлением ключами.

Ключевые метрики для дашборда СХД

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

Типы панелей: Gauge для процента заполнения с цветовыми порогами на 80 и 90, Time series для IOPS и latency, Stat для состояния пулов, Table для топ-5 томов по заполнению. Панель свободного места с палитрой по порогам заметна быстрее, чем список чисел.

Визуализация трендов роста данных

Прогноз заполнения строится функцией predict_linear, которая продолжает текущую линию роста на заданный период.

predict_linear(node_filesystem_avail_bytes{mountpoint="/data"}[6h], 86400 * 30)

Результат - ожидаемый объём свободного места через 30 дней. Условие «расширение нужно в течение месяца» записывается сравнением с 10% от общего размера:

predict_linear(node_filesystem_avail_bytes{mountpoint="/data"}[6h], 86400 * 30)
  < node_filesystem_size_bytes{mountpoint="/data"} * 0.1

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

(node_filesystem_avail_bytes{mountpoint="/data"}
  / deriv(node_filesystem_avail_bytes{mountpoint="/data"}[6h])) / 86400

Окно [6h] сглаживает разовые загрузки и бэкапы, но пропускает резкое ускорение роста. Окно в 7 дней даёт стабильную линию для квартального планирования. Если рост ускоряется, панель покажет сокращение дней до заполнения за несколько часов. Прогнозирование отказов по SMART и питанию разобрано в статье про предиктивный ремонт серверов и СХД.

В Zabbix аналог прогноза даёт триггерная функция timeleft, которая возвращает время до достижения порога:

timeleft(/host/vfs.fs.size[/data,free],80,7d)<86400*14

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

Настройка алертов для СХД в Zabbix и Prometheus

Пороговые значения для алертов

Пороги зависят от роли тома. Для системных разделов и томов баз данных рабочий набор такой: заполнение выше 80% - warning, выше 90% - critical. Тома под логи с автоочисткой держат пороги 90 и 95, иначе алерты превращаются в шум.

По остальным метрикам практика такая:

• Температура HDD выше 50 °C - warning, выше 60 °C - critical; для SSD границы сдвигаются к 60 и 70 °C.
• Reallocated sectors больше нуля - warning, pending sectors больше нуля - critical, диск меняется по плану.
• Состояние пула, отличное от ONLINE, - критический алерт без задержки.
• Latency выше трёхкратной базовой линии за 30 дней - warning, выше пятикратной - critical.
• Любой выход экспортера или агента из строя - critical, иначе метрики исчезают незаметно.

Динамические пороги считаются от истории: quantile_over_time(0.99, node_disk_read_time_seconds_total[30d]) даёт границу, выше которой показатели выбиваются из обычного профиля. Этот подход снимает проблему разной нагрузки на разных СХД.

Интеграция с системами уведомлений

Правила алертов Prometheus описываются отдельным файлом rules.yml.

groups:
  - name: storage
    rules:
      - alert: StorageSpaceLow
        expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes) * 100 < 10
        for: 15m
        labels:
          severity: critical
        annotations:
          summary: "Мало свободного места на {{ $labels.instance }}"
          description: "Точка монтирования {{ $labels.mountpoint }}, свободно менее 10%"
      - alert: ZpoolDegraded
        expr: zpool_health == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Пул ZFS не в состоянии ONLINE на {{ $labels.instance }}"
      - alert: ExporterDown
        expr: up{job="node"} == 0
        for: 5m
        labels:
          severity: warning

Задержка for: 15m отсекает разовые скачки, когда место временно освобождают ротацией логов. Route в alertmanager.yml группирует уведомления по алерту и инстансу, чтобы один упавший сервер не породил десять сообщений.

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: telegram
receivers:
  - name: telegram
    telegram_configs:
      - bot_token: 'TOKEN'
        chat_id: -1001234567890
        send_resolved: true

В Zabbix уведомления настраиваются через медиа-типы: Email, Webhook для Slack и скрипт или webhook для Telegram. В действиях задаётся эскалация: warning уходит один раз, critical повторяется каждые 30 минут до подтверждения. Готовые триггеры для TrueNAS, ZFS и серверного железа собраны в руководстве по настройке Express-уведомлений в Zabbix.

Типичные ошибки при интеграции и как их избежать

• Неверные OID при SNMP. Графики пустые или показывают нули. Решение: прогнать snmpwalk до настройки шаблона и помнить, что hrStorageUsed нужно умножать на hrStorageAllocationUnits.
• Слишком частый опрос. Интервал 15 секунд к SNMP на двухсоттомной СХД загружает процессор контроллера и вызывает таймауты. Решение: 60-120 секунд для сбора, discovery раз в час.
• Устаревшие имена метрик. node_filesystem_free_bytes не учитывает зарезервированные блоки, для алертов нужен node_filesystem_avail_bytes. Сверяйте имена в выводе /metrics после обновления экспортера.
• Недостаточные права. Агент Zabbix не читает /dev/zfs, smartctl без root отдаёт пустой вывод. Решение: группы и capabilities вместо запуска всего агента от root.
• Неатомарная запись .prom файла. Prometheus собирает битую строку и отбрасывает весь файл. Решение: писать во временный файл и делать mv.
• Открытые порты и слабая аутентификация. Community public на SNMP и экспортер, слушающий 0.0.0.0, дают доступ к метрикам инфраструктуры. Решение: firewall, ACL по IP, TLS или basic auth через обратный прокси.
• Рассинхрон времени. NTP на серверах мониторинга и СХД обязателен, иначе алерты и графики расходятся и разбор инцидента занимает вдвое больше времени.
• Мониторинг самого мониторинга. Падение Prometheus или записи в TSDB заканчиваются молчанием, а не алертом. Решение: держать отдельный канал проверки доступности и heartbeat-алерт.

Все изменения проверяйте на стенде: снимите метрики с тестового тома, дождитесь записи в TSDB, посмотрите панели, и только после этого переносите конфиг в продакшен.

Проверка и тестирование интеграции

Проверка начинается с источника данных. Метрики должны отдаваться по сети и содержать нужные лейблы.

curl -s http://localhost:9100/metrics | grep -E 'node_filesystem|zpool_|disk_temperature'
zabbix_get -s 192.168.1.10 -k 'storage.used[/data]'
promtool check rules /etc/prometheus/rules.yml
promtool check config /etc/prometheus/prometheus.yml
amtool check-config /etc/alertmanager/alertmanager.yml

Тест алерта без создания реальной аварии: временно опустите порог ниже текущего значения и дождитесь истечения for. Например, при заполнении 30% поставьте условие выше 20% и проверьте, что уведомление пришло в Telegram, а после отката порога пришло сообщение о восстановлении. В Prometheus состояние правил видно на странице /alerts, в Alertmanager - в веб-интерфейсе.

Проблема «No data» на панели Grafana почти всегда означает расхождение метки или источника: проверьте datasource, интервал времени и точное имя метрики. Полезно добавить алерт на пропажу ключевых серий, чтобы отсутствие данных не выглядело как норма:

absent(node_filesystem_avail_bytes{mountpoint="/data"})

Отдельно заложите retention. Для дискового планирования храните сырые метрики 15-30 дней, а агрегированные значения - до года. В Prometheus это параметры --storage.tsdb.retention.time и recording rules, в Zabbix - настройки истории и трендов. Расчёт места простой: одна серия при интервале 60 секунд даёт 1440 точек в сутки, поэтому тома под TSDB планируют с запасом вдвое от расчётного объёма.

Развернуть весь стек с нуля за один вечер помогает пошаговая инструкция по настройке Prometheus, Grafana и оповещений: там разобраны установка компонентов, подключение источников данных и автоматические уведомления в Telegram, Slack и Email. После проверки связки на стенде переносите конфиги в продакшен и фиксируйте их в системе контроля версий: это единственный способ понять через полгода, почему изменился порог или исчезла панель.