Пять метрик отвечают на большинство вопросов о качестве хранения: доступность, RPO, RTO, число ошибок целостности и заполненность пулов. Задержки ввода-вывода, IOPS и температура дисков уточняют картину, но разговор с руководством и защита бюджета строятся на этой пятёрке, потому что каждая цифра переводится в часы простоя и деньги.
Собирают их стандартной связкой: node_exporter отдаёт метрики файловых систем, zfs_exporter - состояние пулов и датасетов, smartctl_exporter - атрибуты накопителей, SNMP закрывает проприетарные СХД. Prometheus хранит временные ряды, Grafana показывает их на дашборде, а TrueNAS reporting даёт срез по ZFS без отдельного экспортера.
Ниже: формулы расчёта, готовые запросы PromQL, структура дашборда, шаблон отчёта на одну страницу и таблица целевых значений для трёх классов сервисов.
Зачем измерять качество хранения и какие метрики действительно важны
Качество хранения описывают четыре свойства: сервис доступен, данные не повреждены, восстановление после сбоя укладывается в срок, поведение системы предсказуемо под нагрузкой. Каждому свойству нужен измеримый показатель, иначе спор о надёжности превращается в обмен мнениями.
Без цифр бюджет не защитить. Пример: после двухчасового отказа NFS-хранилища администратор говорит, что резервирование «окупилось», но если доступность не измерялась, доказать это нечем. История метрик даёт обратный аргумент: видно, что до перехода на реплику простой составлял 6 часов в год, а после - 40 минут.
Базовый набор метрик выглядит так: доступность системы хранения, RPO, RTO, число ошибок целостности, время восстановления хранилища, заполненность пулов. К ним добавляют задержку операций, IOPS и температуру дисков как диагностический слой.
Метрики привязывают к классам сервисов. Платёжный шлюз и архив черновиков не могут иметь одинаковые цели по RPO: первому нужны потери не больше 15 минут, второму хватает суток. Разделение по классам экономит бюджет и убирает лишние алерты. Логика оценки эффекта от инфраструктурных изменений по метрикам разобрана отдельно: оценка эффективности инфраструктуры и кода после запуска проекта.
Доступность системы хранения: как считать и какой уровень считать нормой
Формула: доступность = (общее время - время простоя) / общее время x 100%.
Первый вопрос при расчёте: что считать простоем. Полная недоступность (пул не смонтирован, сервис не отвечает) очевидна. Деградация, при которой задержка ввода-вывода выросла выше согласованного порога или появились ошибки ввода-вывода, тоже простой, если пользователь не может работать. Методику фиксируют в SLA до первого инцидента, иначе каждый спор решается заново.
Простой бывает плановым и внеплановым. Плановые окна вычитают при трёх условиях: о работах предупредили, они уложились в окно, после них не потребовалось аварийное вмешательство.
Целевые значения в часах и минутах: 99,99% - не больше 52 минут простоя в год; 99,9% - 8 часов 46 минут; 99,5% - 43 часа 48 минут.
Измерять доступность стоит на трёх уровнях: пул, датасет, сервис (NFS, SMB, iSCSI, S3). Уровень пула проверяет, жив ли zpool и отвечает ли он на запросы, уровень сервиса - что клиент реально получает данные. Для сервисного уровня подходит blackbox_exporter с проверкой TCP-портов и чтением тестового файла, для уровня пула - метрика up{job=«zfs»} в Prometheus.
RPO и RTO: как определить допустимые потери и время восстановления
RPO (recovery point objective) - максимальный период, данные за который допускается потерять. RTO (recovery time objective) - максимальное время возврата сервиса в работу после сбоя. RPO отвечает на вопрос «сколько данных потеряем», RTO - «как долго будем лежать».
Практичные значения по классам: критичные сервисы - RPO не больше 15 минут, RTO не больше 1 часа; стандартные - RPO не больше 1 часа, RTO не больше 4 часов; второстепенные - RPO не больше 24 часов, RTO не больше 24 часов.
Фактический RPO измеряют по журналам репликации: берут время последней успешной синхронизации или последнего снапшота (zfs send/recv, расписание снапшотов, лог rsync) и сравнивают с моментом сбоя. Разница и есть реальный RPO. Если она превышает цель, репликацию пересобирают: чаще снапшоты, отдельный сетевой путь, асинхронный режим с журналом.
Фактический RTO получают только на учениях по восстановлению. Замер начинается с команды на восстановление и заканчивается проверкой контрольных сумм или scrub. Результат пишут в метрику restore_duration_seconds через pushgateway, чтобы график восстановления стоял рядом с остальными показателями, а не жил в отдельной таблице.
Как подобрать RPO и RTO под конкретную нагрузку и бюджет, разобрано в методике выбора СХД: выбор системы хранения для DevOps и сисадминов.
Ошибки целостности и заполненность пулов: скрытые угрозы
Ошибка целостности - событие, при котором контрольная сумма блока не совпала с содержимым. ZFS считает такие события в выводе zpool status (колонки READ, WRITE, CKSUM), SMART даёт косвенные признаки: Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable.
Ошибки целостности считают по результатам scrub, а не по факту обращений к данным. Периодичность для ZFS: раз в 1-2 недели для нагруженных пулов, раз в месяц для архивных. Ключевая метрика - прирост ошибок между прогонами: если за очередной scrub появились новые CKSUM, диск меняют по гарантии, даже когда пул ещё в состоянии ONLINE.
В TrueNAS reporting метрики ZFS лежат в разделе Reporting, вкладка ZFS: использование пулов, ошибки, история scrub. Эти же данные доступны через API, если нужно тянуть их в Prometheus, а не смотреть глазами.
Заполненность пула влияет на производительность и на возможность быстро создать снапшот. Порог: держать не выше 80%, а для критичных сервисов не выше 70%, предупреждение на 75%, критический алерт на 85%. Причина в copy-on-write: чем меньше свободных блоков, тем дороже поиск места под новую запись и тем сильнее фрагментация. Как связать рост заполненности с падением скорости, показано в разборе: поиск узкого места в системе.
Как собирать метрики хранения в Prometheus и Grafana
Схема сбора: экспортеры, затем Prometheus, затем Grafana. node_exporter отвечает за файловые системы, нагрузку и сеть, zfs_exporter - за пулы, датасеты и ошибки, smartctl_exporter - за атрибуты дисков, snmp_exporter - за СХД без нативного экспортера (Synology, NetApp, Dell PowerVault). TrueNAS закрывает часть задач штатно: встроенный reporting и API.
Пример scrape_configs:
scrape_configs:
- job_name: zfs
static_configs:
- targets: ['nas-01:9134']
- job_name: smartctl
static_configs:
- targets: ['nas-01:9633']
- job_name: node
static_configs:
- targets: ['nas-01:9100']
- job_name: snmp
metrics_path: /snmp
params:
module: [if_mib]
static_configs:
- targets: ['synology-01']
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- target_label: __address__
replacement: snmp-exporter:9116
Имена метрик у экспортеров меняются между версиями. Перед настройкой алертов откройте страницу /metrics конкретного экспортера и сверьте список: правило, написанное по чужому дашборду, часто молча не срабатывает.
Настройка экспортеров для ZFS и TrueNAS
zfs_exporter запускают на том же узле, где живёт пул: ему нужен доступ к /dev/zfs и право выполнять zpool и zfs.
docker run -d --name zfs_exporter --restart unless-stopped \ --privileged \ -p 9134:9134 \ pdf/zfs_exporter:latest
Проверка занимает одну команду: curl http://nas-01:9134/metrics. В выводе ищите zfs_pool_allocated_bytes, zfs_pool_size_bytes, zfs_dataset_used_bytes и метрики состояния пула.
docker run -d --name smartctl_exporter --restart unless-stopped \ --privileged \ -p 9633:9633 \ prometheuscommunity/smartctl-exporter
TrueNAS отдаёт данные двумя путями: SNMP (сервис включают в интерфейсе, задают community и ACL) и REST API. Учтите расхождения между версиями: в TrueNAS 13 и SCALE ветка API v2.0 отличается от старой v1.0, а в SCALE 24.04 отчётность переведена на netdata вместо collectd, поэтому инструкции с разбором RRD-файлов на новых сборках не работают. Сверяйте версию до копирования конфигурации.
Когда статус scrub нужно держать в Prometheus, помогает textfile collector у node_exporter: скрипт раз в 30 минут вызывает zpool status -x и пишет результат в .prom файл.
zfs_scrub_errors{pool="tank"} 0
zfs_scrub_last_ts{pool="tank"} 1757721600
Файл пишите во временный путь и переносите через mv: node_exporter может прочитать недописанный файл и отдать битую метрику.
Создание дашборда Grafana для СХД
Рабочая структура дашборда для СХД - три ряда панелей.
Верхний ряд: четыре Stat-панели с доступностью за 30 дней, заполненностью самого полного пула, числом ошибок целостности за сутки и временем последнего восстановления.
100 * avg_over_time(up{job="zfs"}[30d])
100 * zfs_pool_allocated_bytes / zfs_pool_size_bytes
increase(zfs_pool_errors_checksum_total[24h])
Средний ряд: ошибки по пулам, температура дисков, прогноз заполнения.
predict_linear(node_filesystem_avail_bytes{instance="nas-01",mountpoint="/mnt/tank"}[7d], 30 * 86400) < 0
smartctl_device_attribute{name="Reallocated_Sector_Ct"} > 0
Нижний ряд: детализация по датасетам, история scrub, глубина очереди и задержка диска. Здесь же уместны панели с probe_success для NFS и SMB, чтобы отказ сетевого пути не выглядел как отказ хранилища.
Дашбордов должно быть два: технический с миллисекундами и байтами и управленческий с процентами, инцидентами и RPO/RTO. Один общий экран быстро превращается в шум для обеих аудиторий.
Полезная деталь для отчётности: переменная «месяц» в управленческом дашборде. Она позволяет собирать один и тот же срез за любой период без правки панелей.
Как свести метрики в единый дашборд для руководства и технической команды
Руководству нужны агрегаты за период: доступность за месяц, число инцидентов, среднее время восстановления, максимальная заполненность пулов, прогноз роста данных на квартал. Команде нужна разбивка по пулам, датасетам, дискам и типам ошибок.
Формат отчёта: одна страница с таблицей KPI, графиком доступности, списком инцидентов и ссылкой на детальный дашборд. Ежемесячной периодичности достаточно; недельная оправдана в период миграции или быстрого роста объёма данных.
Разделение метрик на технические и бизнес-показатели
Технические: задержка ввода-вывода, IOPS, ошибки целостности, температура, глубина очереди, заполненность датасетов, длительность scrub.
Бизнес-показатели: доступность сервиса в процентах и часах простоя, фактические RPO и RTO против целевых, число предотвращённых инцидентов, стоимость простоя, ROI мониторинга.
Пример перевода технического факта в управленческий: руководству не нужна задержка в миллисекундах, ему нужно, что после добавления реплики доступность выросла с 99,5% до 99,9%, то есть простой сократился с 43,8 до 8,76 часа в год. Это минус 35 часов простоя, которые умножают на стоимость часа и получают эффект в деньгах.
Стоимость простоя считают по формуле: потери = часы простоя x выручка (или выработка) в час + стоимость аварийных работ. Условный пример: платёжный шлюз приносит 300 000 рублей в час, значит один час отказа стоит 300 000 рублей прямых потерь плюс работу четырёх инженеров.
Шаблон отчёта для руководства
Структура из четырёх блоков:
- Ключевые KPI за период: доступность, RPO, RTO, количество инцидентов, среднее время восстановления.
- Динамика к прошлому периоду: те же цифры и изменение в процентах или часах.
- Влияние на бизнес: потерянные часы простоя, предотвращённые инциденты, экономия на аварийных закупках.
- План: что меняем в следующем периоде и какой эффект ожидаем.
Визуализации, которые читаются с первого взгляда: линейный график доступности по месяцам, тепловая карта ошибок по пулам, таблица RPO и RTO по сервисам с подсветкой отклонений, столбцы заполненности с прогнозом на 90 дней.
Целевые значения метрик для разных классов сервисов
Класс сервиса определяет требования к резервированию, мониторингу и частоте учений по восстановлению. Готовые значения для трёх классов:
| Класс | Доступность | RPO | RTO | Заполненность пула | Ошибки целостности |
|---|---|---|---|---|---|
| Критичный | 99,99% (до 52 мин в год) | до 15 мин | до 1 ч | до 70% | 0 |
| Стандартный | 99,9% (до 8,76 ч в год) | до 1 ч | до 4 ч | до 80% | 0 |
| Второстепенный | 99,5% (до 43,8 ч в год) | до 24 ч | до 24 ч | до 85% | 0 |
Примеры: критичный - платёжный шлюз, транзакционная база, брокер сообщений; стандартный - корпоративная файловая шара, внутренний Git, кэш CI; второстепенный - архив, стенд разработки, долгосрочное хранилище резервных копий.
Значения корректируют под бюджет и риски. Переход с 99,9% на 99,99% означает синхронную репликацию, второй контроллер и дежурную смену: стоимость растёт кратно. Для архива такие вложения обычно не окупаются, а для платёжного сервиса дешевле обходятся, чем один час простоя в квартал.
Как определить класс сервиса
Четыре критерия дают ответ за несколько минут: сколько выручки теряется за час простоя, сколько пользователей затронуто, есть ли регуляторные требования к срокам хранения и восстановления, можно ли отложить работу сервиса на сутки без последствий.
Практика: если сервис влияет на выручку и сутки простоя неприемлемы, класс критичный. Если сервис нужен в рабочие часы, но сутки переживёт, класс стандартный. Если данные можно достать из бэкапа за день и никто не заметит, класс второстепенный.
Типичные ошибки при внедрении метрик хранения и как их избежать
Пять ошибок сводят на нет пользу от мониторинга:
- Нет пороговых значений. Метрика без порога бесполезна: «доступность 99,87%» ничего не значит, пока не решено, что норма 99,9%.
- Слишком чувствительные алерты. Уведомление на заполненность при 70% срабатывает постоянно и приучает игнорировать письма. Порог 80%, предупреждение на 75%, аварийный алерт на 85% дают время отреагировать без шума.
- Плановые простои попадают в статистику наравне с авариями. Окна обслуживания помечают аннотациями в Grafana и вычитают из расчёта, иначе доступность выглядит хуже, чем есть.
- Нет учений по восстановлению. RTO, который не проверяли на практике, остаётся предположением. Для критичных сервисов восстановление на тестовом стенде проводят минимум раз в квартал.
- Разные команды считают по-разному. Если сетевые инженеры считают простой сервиса, а администраторы хранилища - простой пула, цифры в отчёте не сойдутся.
Методику расчёта документируют на одной странице: формула, источники данных, что считается простоем, как учитываются плановые работы. Такой документ снимает половину споров и делает отчёт воспроизводимым. Подробный чек-лист по ошибкам построения мониторинга: типовые ошибки при разработке систем мониторинга.
Автоматизация сбора и отчётности по метрикам хранения
Сбор автоматизируют Prometheus с экспортерами: настроили один раз, дальше данные копятся сами. Ручной труд остаётся в отчётности: выгрузка, сводка, отправка. Здесь и появляется экономия времени.
Минимальный вариант автоматизации: скрипт забирает значения через HTTP API Prometheus и формирует сводку.
import requests
PROM = 'http://prometheus:9090/api/v1/query'
def q(expr):
r = requests.get(PROM, params={'query': expr}, timeout=10)
return float(r.json()['data']['result'][0]['value'][1])
availability = q('100 * avg_over_time(up{job="zfs"}[30d])')
fill = q('100 * max(zfs_pool_allocated_bytes / zfs_pool_size_bytes)')
print(f'Доступность: {availability:.3f}%')
print(f'Максимальная заполненность: {fill:.1f}%')
Дальше результат рендерят в PDF или забирают скриншот панели через Grafana Image Renderer. Запуск ставят в cron на первое число месяца и отправляют готовый файл в почту или мессенджер. Пороговые проверки в скрипте дублируют логику алертов: если доступность ниже цели, отчёт помечается как требующий разбора.
Связка Prometheus, Grafana и агрегаторов метрик требует сервера, который работает круглосуточно и переживает рост ретенции. Такую задачу закрывает облачная инфраструктура с гибким изменением ресурсов: Timeweb Cloud.
TrueNAS API позволяет забирать данные о пулах и дисках программно: например, метод /api/v2.0/pool возвращает список пулов со статусом и потреблением. Перед использованием проверьте версию: в SCALE это ветка v2.0, в CORE поведение отличается, а в 24.04 отчётные endpoint-ы завязаны на netdata.
Аномалии удобнее разбирать не по одному графику, а по сводке: выгрузка метрик за сутки, поиск отклонений от базовой линии, затем ручная проверка подозрительных точек. Текстовую сводку и гипотезы по отклонениям можно формировать через LLM API, а единый доступ к моделям без VPN даёт агрегатор AiTunnel.
Заключение: как выстроить систему метрик хранения с нуля
Порядок действий, который работает на большинстве инфраструктур:
- Определите классы сервисов и целевые значения для доступности, RPO, RTO, заполненности и ошибок целостности.
- Зафиксируйте шесть базовых метрик, диагностические панели добавляйте позже.
- Разверните экспортеры и Prometheus, проверьте каждую метрику через /metrics до настройки алертов.
- Соберите два дашборда в Grafana: технический и управленческий.
- Настройте алерты только на критические события: деградация пула, заполнение выше 85%, новые ошибки целостности, отказ scrub.
- Автоматизируйте отчёт через cron, скрипт и PDF или скриншот дашборда.
- Раз в квартал пересматривайте цели и пороги: рост данных меняет прогноз заполнения, а новые версии ПО меняют имена метрик.
Начинайте с критичных сервисов: они дают быстрый эффект и понятный аргумент для бюджета. Первый отчёт с реальными цифрами обычно выявляет два-три узких места, о которых до этого не догадывались. Все конфигурации из статьи проверяйте на своей версии TrueNAS, ZFS и экспортеров: между релизами меняются API, имена метрик и способ отчётности, поэтому сверка с документацией конкретной сборки обязательна.