🟢 Статус: Conceptually stable · v0.1

Концепция устойчива, проверена опытом, литературой и практикой.

11. Дашборды и отчётность: дизайн витрин

Дашборды и отчёты — это витрина мониторинга. То, что в итоге видят люди, принимающие решения: дежурный, тимлид, владелец сервиса, CIO, директор завода. От качества витрины зависит, сработает ли вся остальная конструкция: сбор метрик, корреляция событий, runbooks — всё это бесполезно, если дежурный не понимает, что показано на экране, а CIO видит «зелёную галочку» вместо реальной картины.

Эта глава — про дизайн витрин как методику, а не сборник скриншотов «красивых дашбордов из Grafana».

После главы 5 — Многоуровневый дизайн у нас есть единый язык тегов. Эта глава показывает, как этим языком пользоваться для главной потребительской подсистемы мониторинга.

---

1. Дашборд — это продукт, не коллекция графиков

Самая частая ошибка дизайна дашбордов: их рассматривают как технический артефакт («набросаем сюда все графики, которые могут пригодиться»). Это приводит к экранам с 40+ виджетами, на которые никто не смотрит.

Дашборд — это продукт, и у него есть:

• Аудитория. Кто конкретно смотрит. Не «руководство», а «дежурный смены 2-й линии в 3 ночи».
• Цель. Что человек должен понять или сделать за первые 5 секунд.
• Refresh rate. Каждые 10 секунд для NOC, раз в час для CIO, раз в день для отчёта.
• Контекст использования. Большой экран в дежурке без звука vs ноутбук в кафе vs телефон в дороге.
• Срок жизни. NOC-дашборд работает годами. Дашборд под конкретный инцидент живёт неделю.

Если на эти пять вопросов нет ответа — это не дашборд, это набор несвязанных виджетов.

Три измерения дизайна

Измерение	Вопрос	Пример ответа
Аудитория	Кто смотрит и в каком состоянии	Дежурный, 3 ночи, после звонка
Цель	Что должен понять за 5 секунд	«Что горит и куда смотреть»
Действие	Что должен сделать дальше	Открыть runbook по подсвеченному сервису

Дашборд без этих трёх ответов — мусор, неважно, насколько красиво он выглядит.

---

2. Аудитория → цель → refresh → формат

Матрица, которая разводит дашборды до проектирования:

Аудитория	Цель	Refresh	Формат	Где живёт
NOC / дежурный	Что горит сейчас, куда эскалировать	30–60 сек (10 сек создаёт нагрузку без практической пользы)	TV full-screen, dark mode	Grafana или Zabbix native
Per-service team	Здоровье одного бизнес-сервиса	1 мин	Web-страница, любое устройство	Grafana
Тимлид эксплуатации	Тренды и горячие точки команды	5 мин	Web + ежедневный дайджест	Grafana + Mattermost
CIO / руководитель ИТ	Бизнес-витрина по сервисам	1 час	Web + monthly PDF	Grafana + Email
Директор завода	«Всё ли работает у нас?»	1 раз в день	Email от CIO, не дашборд	Email
ИБ	Инциденты ИБ, audit trail	1 мин	Web + alerts	Grafana + SIEM
SCADA / OT	Связь IT↔OT, доступность шлюзов	1 мин	Отдельный сегмент, read-only	Grafana, изолированно

Каждая строка — отдельный дашборд с собственным дизайном. Попытка сделать «один дашборд для всех» проваливается всегда, потому что цели разные.

---

Дашборды по аудиториям — детально

Главный принцип повторю: один дашборд — одна аудитория — одна цель. Не «универсальный обзор» — это всегда хуже специализированного.

1. NOC / дежурный (главный экран)

Цель: оператор за 3 секунды понимает, что горит сейчас.

┌─────────────────────────────────────────────────────┐
│  🔴 ACTIVE DISASTERS              (большой баннер)  │
│  • 1C-ERP веб-публикация, упала 14:23, 18 минут     │
│  • Exchange DAG split-brain, 14:25                  │
├─────────────────────────────────────────────────────┤
│  🟡 ACTIVE HIGH (8)                                  │
│  • srv-files-03: disk 90%                           │
│  • UserGate-2: HA out of sync                       │
│  ...                                                 │
├─────────────────────────────────────────────────────┤
│  Service Health Grid (по бизнес-сервисам)           │
│  ┌────┬────┬────┬────┬────┬────┬────┐              │
│  │1С  │EXC │SCADA│DFS │WEB │PRT │BCK │              │
│  │🟢  │🟢  │🟢   │🟡  │🟢  │🟢  │🟢  │              │
│  └────┴────┴────┴────┴────┴────┴────┘              │
├─────────────────────────────────────────────────────┤
│  Last 24h incident timeline                         │
│  (горизонтальная полоска с метками срабатываний)    │
└─────────────────────────────────────────────────────┘

Технические требования: - На большом экране (TV) в дежурке, full-screen - Auto-refresh 30–60 сек (10 сек достаточно редко нужно и создаёт нагрузку на БД; calibrate под реальную потребность) - Только prod (env=prod), без шума test/dev - Надёжный алертинг — через action/media/on-call (Telegram, SMS, звонок), а не через звуковой сигнал дашборда; дашборд — визуальная витрина, не система оповещения - Никаких CPU-графиков. Дежурный не разбирает CPU, он эскалирует

Где делать: Grafana (если есть) или native Zabbix dashboard. Grafana предпочтительнее — гибче, лучше выглядит.

2. Per-service дашборды (для профильных команд)

Один дашборд = один бизнес-сервис, фильтр через тег service=.... Каждой команде — свой набор.

Пример: 1C-ERP team dashboard - Состояние всех хостов сервиса (свежий список) - Очереди фоновых заданий (тренд за 24h) - Активные сессии (тренд) - Использование лицензий HASP - TOP-5 проблемных триггеров за неделю - MSSQL: deadlocks, длинные транзакции, blocking - Размер БД и I/O latency

Пример: Network team dashboard - Состояние всех коммутаторов и маршрутизаторов - Топ-10 интерфейсов по загрузке - Ошибки на портах (errors/discards rate) - BGP peering state - VPN-туннели UserGate (вверх/вниз) - HA cluster sync state

Принципы: - 5-7 виджетов максимум, не больше - Период по умолчанию — последние 24 часа - Везде variables/templating, чтобы один dashboard на все хосты сервиса - На каждом виджете — ссылка на соответствующий runbook («Что делать если этот график красный»)

3. Тимлид / руководитель ИТ-эксплуатации

Цель: понять как работает команда и где боль.

• MTTD (mean time to detect) — тренд по неделям, по сервисам
• MTTR (mean time to resolve) — то же самое
• Number of incidents by severity — недельные столбики
• Top 10 noisy alerts — для понимания «что чинить в шаблонах»
• Coverage % по сервисам — какие сервисы покрыты лучше/хуже
• Acknowledge rate — сколько алертов получили acknowledgement vs ушли в auto-resolve без реакции (показатель работы дежурной службы)
• % алертов с runbook — процесс-метрика, как идёт документирование

Период: обновление ежедневно, смотрят раз в неделю.

4. CIO / директор по ИТ

Цель: «всё ли в порядке в моём хозяйстве» + материал для разговора с генеральным.

┌─────────────────────────────────────────────────────┐
│ Доступность бизнес-сервисов за месяц                │
│                                                      │
│ 1C-ERP            99.87%  🟢  SLA: 99.5%            │
│ Exchange          99.95%  🟢  SLA: 99.5%            │
│ Файловые шары     99.42%  🟡  SLA: 99.5%            │
│ Print services    99.99%  🟢  SLA: 99.0%            │
│ SCADA-bridge      100.0%  🟢  SLA: 99.9%            │
│ DFS               99.78%  🟢  SLA: 99.5%            │
│                                                      │
├─────────────────────────────────────────────────────┤
│ Инциденты за месяц                                   │
│ P1: 2  (предыдущий: 4)  ↓                          │
│ P2: 11 (предыдущий: 14) ↓                          │
│ P3: 47 (предыдущий: 52) ↓                          │
└─────────────────────────────────────────────────────┘

Принципы: - Никаких CPU/диск/сеть. CIO их не интерпретирует. - Зелёный/жёлтый/красный — главное визуальное сообщение - Тренды month-over-month — показывают что становится лучше - Один экран. Если не помещается — сокращать, а не добавлять вкладки

5. Директор завода / производство

Цель: «работает ли ИТ для завода».

• 1С работает: 🟢
• Почта работает: 🟢
• Печать работает: 🟢
• Файлы доступны: 🟢
• Время с последнего серьёзного сбоя: 14 дней

Принципы: - Максимум 5-7 строк - Формулировки на языке бизнес-сервиса, без низкоуровневых технических деталей - Возможно — обновление раз в день (не в реальном времени) - Часто — формат для скриншота на еженедельной планёрке у генерального

⚠️ Согласуй с CIO, нужен ли вообще такой дашборд. Иногда это политически сложно — генеральный начнёт спрашивать «а почему жёлтый» в неудобное время.

6. ИБ / безопасность

Отдельная история, согласовывается с ИБ-службой: - Failed logins (тренд) - Privileged accounts activity - Изменения в Group Policy - Aномальные сетевые потоки - Out-of-hours access (вход в административные системы вне рабочего времени) - Состояние антивируса/EDR на хостах - Возраст последнего успешного бэкапа (важно для антирансомвейр-метрики)

7. SCADA / OT (отдельный)

Категорически не смешивать с IT-дашбордами. Аудитория — инженеры АСУ ТП и OT-команда; у этого контура своя логика. - ICMP latency до bridge-хостов и OPC-серверов (только согласованные read-only проверки; прямое зондирование PLC-сегментов — только после оценки риска с командой АСУ ТП) - Состояние bridge-хостов между IT и OT - Доступность OPC-сервера снаружи (TCP) - Никаких internal SCADA-метрик — для этого уже есть MasterScada/Wonderware

---

12. Как теги питают виджеты

Это место, где глава 5 — Многоуровневый дизайн встречается с практикой. Каждый виджет дашборда должен читать теги, а не зашитые имена хостов.

Таблица: какой тег → какому виджету

Виджет	Какие теги фильтрует	Пример запроса
Service Health Grid на NOC	service, env=prod	Все хосты с service=1c-erp AND env=prod, агрегировать статус
Per-team incident list	owner	WHERE owner=it-apps AND severity>=High
Capacity widget (top N)	scope=capacity, component=*	Все items с scope=capacity, отсортировать по утилизации
SLA gauge	service	Расчёт availability за месяц по service=1c-erp
Drill-down by location	location	WHERE location=dc-main, потом разворот по service
Backup status (Veeam)	component=backup, scope=recovery	Все triggers по бэкапам, отсортировать по возрасту
Hardware health	component=hardware, os_family=*	iLO/iDRAC статус, агрегировать по location
Synthetic checks	component=synthetic	Все synthetic-тесты, фильтр по service

Правило одного источника правды

Если для нового дашборда требуется добавить новое поле на хост — это сигнал, что в tag schema есть дыра.

Дашборд должен читать метаданные, а не придумывать свои. Если регулярно появляется потребность в новых полях для дашбордов — значит, tag schema недостаточна и её нужно расширить как единый артефакт, а не патчить ради конкретного дашборда.

Паттерн детализации: от обзора к компоненту

Это сильный паттерн, который превращает разрозненные дашборды в связную систему:

Executive view (CIO)
   "Сервисы зелёные / 1 жёлтый / 0 красных"
        │
        ▼ клик на 1C-ERP (жёлтый)
        │
Per-service dashboard
   "1С-ERP: SLA 99.7%, активных алертов: 2, последний инцидент: 12:43"
        │
        ▼ клик на компоненту "rphost issues"
        │
Component drill-down
   "RPhost процессы: график за час, активные locks, MSSQL deadlocks"
        │
        ▼ клик на конкретный хост
        │
Host page (Zabbix)
   Все метрики хоста, открытые проблемы, runbook URLs

Каждый уровень — отдельный дашборд, но они связаны через теги (service, component, host name). Пользователь движется от общего к частному за 2–3 клика, без поиска «а где же дашборд про rphost?».

В Grafana это реализуется через Data Links: в виджете указывается URL шаблон вида /d/per-service?var-service=${__series.name} — клик передаёт значение тега в следующий дашборд как variable.

---

13. Где жить дашбордам: Zabbix native vs Grafana

Аспект	Native Zabbix Dashboards	Grafana
Скорость разработки	Средняя	Высокая
Гибкость визуализации	Средняя (в 6.x/7.x значительно улучшилась)	Высокая
Готовые виджеты Zabbix	Problems, Problems by severity, Top hosts/items/triggers, SLA report, Web monitoring, Gauge, Navigator, Actions	Через datasource plugin
Templating / variables	Базовый	Мощный
Альтернативные datasources (Loki, Prometheus, БД)	Нет	Да
Drill-down между дашбордами	Базовый	Гибкий, через Data Links
Дополнительная инфраструктура	Не нужна	Нужен сервер Grafana
Кому: NOC + быстрый старт	✅ Да, особенно для Problems/Events	Если уже есть Grafana — тоже
Кому: длительная эксплуатация	Достаточно для многих сценариев	✅ Лучше для executive/drill-down
Поддерживаемость через GitOps	Сложно (XML export)	Через JSON manifests + ConfigMaps

Эмпирическое правило:

• Native Zabbix Dashboards — для NOC и быстрого старта, если Grafana ещё нет
• Grafana — для всех остальных дашбордов, особенно executive/SLA-витрин и drill-down паттернов
• Power BI / Tableau — для отчётности уровня финансовой отчётности, не для оперативного мониторинга

Grafana подключается к Zabbix через Grafana Zabbix datasource plugin — плагин сообщества, поддерживаемый совместно сообществом и Grafana Labs (не официальный продукт Zabbix LLC). Умеет читать items, triggers, events с фильтрацией по тегам.

Что брать откуда

Нужно	Источник
Real-time метрики	Zabbix (через Grafana datasource)
Active problems / events	Zabbix Events
История ≥ 3 месяцев	Постгрес репликa или TimescaleDB поверх Zabbix history
SLA расчёты	Native Zabbix SLA report (Services → SLA report) + SLA report dashboard widget; для кастомных расчётов — Zabbix API
Логи (parallel view)	Loki / ELK / Graylog как separate datasource
Custom metadata (CMDB)	Внешняя БД (Netbox/iTop), читать в Grafana как SQL datasource

---

Регулярная отчётность — что, кому, когда

Принципы

• Автоматизация >> ручная сборка. Отчёт собирающийся 2 дня руками — не отчёт, это случайность
• Push, не pull. Отчёт отправляется получателю в почту/чат, а не «зайдите посмотрите на дашборд»
• Один отчёт — одна цель. Не «универсальный отчёт обо всём», а «месячная доступность сервисов»

Целевая матрица отчётности

Отчёт	Получатель	Период	Источник	Доставка
Daily NOC summary	Дежурная служба, тимлид	ежедневно 9:00	Zabbix events за сутки	Email + Mattermost/Telegram канал
Weekly operations	ИТ-команда + тимлид	пн 9:00	агрегация за неделю	Email + Bookstack page
Monthly SLA report	CIO + руководители команд	1 число	Grafana → PDF	Email
Monthly executive	CIO для директора завода	1 число	сжатый SLA-отчёт	Email от CIO, не от ИТ
Quarterly capacity review	CIO + ИТ-руководство	раз в квартал	тренды ресурсов	Очная встреча + презентация
Incident postmortems	По каждому P1	в течение 5 рабочих дней	шаблон в Bookstack	Email команде + архив в Bookstack
Alert hygiene report	Тимлид	раз в 2 недели	топ noisy alerts	Mattermost канал команды

Как генерируется автоматически

Лёгкий путь: Grafana → Reporting (есть в Grafana Enterprise, но и в OSS можно через grafana-image-renderer + cron).

Бесплатный путь: скрипт на Python: - Тянет данные через Grafana API или Zabbix API - Рендерит в HTML по шаблону (Jinja2) - Конвертирует в PDF (WeasyPrint) - Шлёт почтой через корпоративный SMTP

# Скелет
from jinja2 import Template
import weasyprint
import smtplib

# 1. Собрать метрики (zabbix API)
metrics = collect_monthly_metrics()

# 2. Отрендерить
html = Template(open("monthly_sla.j2").read()).render(metrics=metrics)

# 3. PDF
pdf = weasyprint.HTML(string=html).write_pdf()

# 4. Отправить
send_email(to=cio_email, subject="ИТ-отчёт за май", attachment=pdf)

Это разовая работа на 2-3 дня + потом cron-job. Никто отчёт не собирает руками после этого.

⚠️ Для автоматических отчётов: используйте выделенный service account с минимальными правами (read-only); Zabbix API token и SMTP credentials — через secrets manager или CI variables, не в plain скрипте; проверьте что отчёт не содержит чувствительных данных (пароли, внутренние IP, данные КИИ) перед отправкой на внешние адреса.

---

14. Автоматизация отчётности

Отчёт, который собирается руками 2 дня — это не отчёт, это случайность. Реальная отчётность всегда автоматизирована.

Способы

Метод	Подходит для	Сложность
Grafana Reporting (Enterprise)	PDF снимок дашборда раз в N	Низкая (если есть Enterprise license)
Grafana panel render API + cron	PNG/PDF снимок панели в email	Средняя
Zabbix Reports (Scheduled Reports)	Native scheduled PDF из dashboard	Низкая, но менее гибко
Скрипт + Zabbix API + Jinja2	Кастомный HTML/PDF отчёт	Высокая, но максимально гибко
Внешний BI (Metabase / Superset)	Сложные SQL-отчёты по истории	Высокая, отдельная инфраструктура

Для большинства задач достаточно Grafana panel render API + cron на простом скрипте: один cron-job в день рендерит нужные панели в PNG, склеивает в одну email и отправляет.

Чёткий формат отчёта

Каждый автоматический отчёт должен иметь:

• Тему с датой и обозначением периода: [SLA Monthly] 1C-ERP за апрель 2026
• Sender — функциональный адрес, не личный (monitoring@example.com)
• Body — 3–5 строк прозы с выводами, не таблицей цифр
• Вложение — PDF/PNG с детализацией
• Ссылка на live-дашборд в конце письма
• Контакт по вопросам — кому писать, если непонятно

Без выводов в body — отчёт превращается в спам. Получатель открывает, видит таблицу, закрывает, через год удаляет правило «monitoring → archive».

---

15. Anti-patterns дашбордов

Локальная сводка ошибок именно в дизайне дашбордов. Общие anti-patterns — в главе 15.

❌ Один дашборд на всех. "Master dashboard" с 40 виджетами не работает ни для NOC, ни для CIO. Делается по аудиториям.

❌ CPU/RAM на дашборде CIO. CIO не читает CPU. Ему нужны сервисы. Технические метрики — на per-team дашборде.

❌ Зелёная галочка как availability > 0%. Сервис либо «работает» по критерию пользовательского пути (synthetic), либо «не работает». Не «50% хостов доступны».

❌ Refresh rate 10 секунд на дашборде CIO. Бессмысленный нагрузочный шум. CIO смотрит в дашборд раз в день, ему refresh 1 час хватит.

❌ Цвет от настроения, а не от логики. На NOC-дашборде Disaster — красный, High — оранжевый, Average — жёлтый. Везде. Не отдельно для каждого виджета.

❌ Графики без подписей оси Y. Что это — проценты? Байты? Секунды? Если непонятно с первого взгляда — виджет не работает.

❌ Текст 8pt на TV-экране. NOC-экран висит в 5 метрах от дежурного. Шрифт ≥ 18pt, контраст высокий, тёмная тема.

❌ Хардкод имён хостов в дашборде. Через месяц хост переименовали → дашборд сломан. Используйте теги.

❌ Дашборд без owner. Через полгода никто не помнит, чей это дашборд и зачем. Каждый дашборд имеет владельца и тег в title ([1C-ERP][owner: it-apps]).

❌ «Бета-дашборд» вечно. Если дашборд год в beta — это значит, никто его не использует. Удалить.

❌ Дашборд под конкретный инцидент остался жить. Сделали под P1 на прошлой неделе → положили в /tmp папку Grafana → удалить через 7 дней.

❌ Reporting без выводов. «Месячный отчёт по доступности» с таблицей и без единого предложения о том, что это значит — спам.

---

16. Design checklist

Перед публикацией нового дашборда — пройдите по списку:

Аудитория и цель:

• Аудитория определена конкретно (не «ИТ-команда», а «дежурный смены 2»)
• Цель сформулирована в одной фразе («понять, что горит за 5 секунд»)
• Определено целевое действие после взгляда на дашборд
• Refresh rate соответствует роли (10с для NOC, 1ч для CIO)
• Контекст использования учтён (TV, ноутбук, телефон)

Содержание:

• Количество виджетов ≤ 10 (для NOC) или ≤ 8 (для остальных)
• Каждый виджет имеет понятный заголовок и единицы измерения на оси
• Цветовая дисциплина соблюдена (красный = действовать, жёлтый = смотреть)
• Технические метрики (CPU/RAM) — только на per-team дашбордах, не на executive
• Виджеты читают теги как основной источник (не хардкод имён хостов); явный список критичных компонентов допустим как часть service definition, если тегов недостаточно

Данные:

• Источник данных понятен (Zabbix / Loki / SQL replica)
• Фильтр по env=prod явно задан (нет смеси с test/dev)
• Drill-down ведёт на per-service / per-host дашборд через Data Links
• Запросы не убивают БД (на исторических данных — replica, не master)

Доставка:

• Дашборд имеет владельца (тег в title)
• Дашборд имеет дату последнего разбора
• Ссылка на дашборд встроена в runbook'и через {TRIGGER.URL} или в Wiki
• Reporting (если есть) приходит на функциональный адрес, не личный
• Каждый отчёт имеет выводы в body, не только вложение

---

Резюме

1. Дашборд — это продукт. Аудитория, цель, действие, refresh, контекст — без них дашборд не работает
2. Один дашборд — одна аудитория — одна цель. Не пытайтесь сделать «универсальный» дашборд
3. Семь основных типов дашбордов: NOC, per-service, team, CIO, executive, ИБ, OT
4. Виджеты читают теги, не хардкод имён. Tag schema из главы 3 — единый источник правды
5. Drill-down паттерн: executive → service → component → host. Через Data Links в Grafana
6. Reporting автоматизирован. Push, не pull. Каждый отчёт имеет выводы в body
7. Если для дашборда нужно новое поле на хосте — это дыра в tag schema, не в дашборде

См. также:

• Глава 3 — Теги и группы — что и куда вешать
• Глава 5 — Многоуровневый дизайн — общая методика, на которой строятся дашборды
• Глава 10 — SLA — что считать в SLA-витринах
• Глава 15 — Anti-patterns — общая сводка ошибок