Как создать систему дашбордов для мониторинга ИТ‑инфраструктуры

Системный администратор, DevOps-инженер или ИТ-руководитель рано или поздно сталкивается с проблемой: как видеть состояние всей инфраструктуры в едином окне, получать оповещения до того, как проблема затронула пользователей, и быстро находить первопричину сбоя? Решение — дашборды мониторинга: без этого инструмента сегодня сложно представить профессиональную эксплуатацию ИТ-систем.

Разберем, из чего состоит система дашбордов, какие метрики в нее добавлять, как пошагово создать дашборд мониторинга, и какой инструмент выбрать: Grafana или российский аналог «Графиня».

Разобраться в теме нам помогает Дмитрий Унтила, CPO «Пульта» и «Графини» в «Лаборатории Числитель», более 10 лет работающий с системами мониторинга.

Дашборд мониторинга — это визуальный интерфейс, который объединяет метрики из разных источников данных и отображает их в режиме реального времени. В отличие от журналов (логов) или сырых данных из БД, дашборд превращает поток цифр в наглядную картину: графики загрузки CPU, индикаторы состояния сервисов, таблицы задержек сетевых запросов.

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

Единое окно наблюдения. Современная инфраструктура гетерогенна: физические серверы, виртуальные машины, контейнеры Kubernetes, облачные сервисы, сетевое оборудование. Дашборд системы мониторинга сводит все эти данные в одном месте и отображает их под правильным «углом».

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

Любая зрелая система дашбордов включает три ключевых компонента: источники данных, типы панелей и механизмы шаблонизации.

Источник данных (data source) — это подключение к системе, которая хранит или генерирует данные о состоянии инфраструктуры. Выделяют три основных типа:

• Метрики — числовые измерения во времени: загрузка CPU, объем памяти, количество запросов в секунду, задержка ответа. Для хранения метрик чаще всего используют Zabbix, Prometheus или VictoriaMetrics. Обычно данные хранятся в виде временного ряда: каждое значение привязано к метке времени.
• Логи — текстовые записи событий. Хранятся в таких системах, как Elasticsearch или Loki. Логи детализируют то, что метрики показывают на уровне тренда: конкретные ошибки, стек-трейсы, пользовательские действия.
• Трассировки (traces) — записи пути запроса через распределенную систему. Они позволяют понять, на каком микросервисе возникает задержка или сбой. Используются совместно с такими инструментами, как Jaeger или Zipkin.

Панель (виджет) — это элемент дашборда, визуализирующий данные из одного или нескольких источников.

Основные типы панелей:

• Графики временного ряда наиболее распространены и отображают изменение метрики во времени: нагрузку сервера за последние 24 часа, трафик сети за неделю.

«Светофоры» состояния могут иметь бинарный или статусный вид: зеленый / желтый / красный. Идеальны для оперативного понимания кондиции сервисов.

Переменная (variable) — механизм, позволяющий сделать дашборд динамическим. Вместо жестко заданного имени хоста или сервиса в запрос подставляется значение из выпадающего списка. Пользователь выбирает «prod-server-01» или «dev-server-02», и весь дашборд перестраивается.

Помимо простых константных переменных, поддерживаются и динамические: значения подтягиваются из источника данных в реальном времени. Это избавляет от необходимости обновлять дашборд при каждом добавлении в инфраструктуру нового сервера или контейнера. Шаблонизация (темплейтинг) идет еще дальше: виджет клонируется для каждого значения переменной. Если в инфраструктуре 10 серверов, достаточно создать один виджет — система автоматически развернет 10 копий с соответствующими данными.

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

Базовый дашборд системы мониторинга физической и виртуальной инфраструктуры обычно включает так называемые метрики из согласованной в компании «Модели здоровья»:

Серверы: загрузка процессора (CPU utilization), использование оперативной памяти (RAM), дисковый ввод-вывод (disk I/O), свободное место на дисках, средняя нагрузка (load average).

Сеть: пропускная способность (bandwidth) входящего и исходящего трафика, количество пакетов, потери пакетов, задержки (latency), состояние сетевых интерфейсов.

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

На уровне приложений ключевые метрики: частота запросов (RPS), процент ошибок (Error Rate), время ответа (Latency — p50, p95, p99), глубина очередей, количество активных соединений с базой данных, время выполнения запросов.

Эти метрики формируют так называемые «золотые сигналы» наблюдаемости, впервые описанные в книге Google SRE: Latency, Traffic, Errors, Saturation (LTES). Грамотно выстроенный дашборд для ИТ покрывает все четыре.

Современные платформы визуализации не ограничиваются системными метриками. Через универсальные коннекторы (CSV, JSON, HTTP API) можно подключить практически любой источник данных: показания датчиков, данные из ERP-систем, статистику бизнес-приложений.

Отдельно стоит упомянуть интеграцию с IP-камерами. Запрос «камера в дашборд графана» встречается среди практиков достаточно часто. Технически это реализуется через MJPEG-стрим или RTSP-поток, преобразованный в HTTP-ссылку, которую можно вывести на панель в виде медиа-виджета.

Ниже описан универсальный процесс, применимый к любой платформе — будь то Grafana или ее российский аналог «Графиня».

Прежде чем создать дашборд, ответьте на три вопроса:

— кто будет им пользоваться (дежурный инженер, DevOps-команда, ИТ-директор)?

— для каких целей (оперативный контроль, расследование инцидентов, отчетность)?

— в каком контексте (мониторинг конкретного приложения, всей инфраструктуры, отдельного дата-центра)?

Ответы определяют дальнейшие шаги: набор метрик, уровень детализации и форму подачи. Дашборд для дежурного администратора насыщен деталями и алертами; дашборд для руководства — крупными индикаторами состояния и трендами.

Следующий шаг — подключение к системам, которые хранят нужные метрики. Типовой стек для мониторинга ИТ-инфраструктуры: Zabbix или Prometheus / VictoriaMetrics для метрик, Elasticsearch или Loki для логов, PostgreSQL или ClickHouse для хранения агрегированных данных.

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

Начинать с пустого листа необязательно. В открытой библиотеке Grafana есть тысячи готовых дашбордов для популярных источников: Prometheus, Zabbix, PostgreSQL, Kubernetes. Например, для мониторинга серверов через Node Exporter часто берут дашборд Node Exporter Full. Его импортируют по ID или из JSON-файла, а затем убирают лишние панели и настраивают пороги под свои задачи.

В «Графине» настройка дашбордов, как и работа с Grafana, строится по единому принципу: для каждой панели пишется запрос, затем выбирается тип визуализации. В Prometheus-совместимых системах запросы можно писать на языке PromQL; для SQL-баз — на SQL; для Zabbix-совместимых систем обычно доступен визуальный конструктор запросов. Процесс создания дашбордов в Grafana и "Графине" полностью идентичен.

Так же переносятся и готовые дашборды из библиотеки Grafana: достаточно загрузить JSON-файл в «Графиню» и проверить, правильно ли подключились источники данных.

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

Платформы визуализации позволяют объединять данные из разных источников на одной панели — например, выводить метрики производительности из Prometheus вместе со списком событий из Zabbix или «Пульта». Это один из ключевых сценариев, ради которых и существует отдельный слой визуализации поверх систем мониторинга.

Дашборд без алертов — это инструмент для ретроспективного анализа, но не для проактивного мониторинга. Алерт (alert) — это правило, которое срабатывает при выходе метрики за заданный порог и отправляет уведомление в нужный канал: Telegram, Slack, электронную почту, систему управления инцидентами.

Функционал алертинга в «Графине» находится в активной разработке и появится во второй половине 2026 года. Функциональность On-Call (управление дежурными сменами) будет реализована на следующем этапе — после выхода базового алертинга и получения обратной связи от пользователей.

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

В корпоративной среде дашборды должны быть доступны разным группам пользователей с разными правами. Типовая модель в «Графине» включает несколько ролей: наблюдатель (только просмотр), оператор (создание и редактирование собственных дашбордов), продвинутый оператор (редактирование всех дашбордов в рамках организации), администратор (управление подключениями и пользователями).

Большинство платформ поддерживают интеграцию с корпоративными системами авторизации (LDAP и SAML), что позволяет автоматически назначать роли на основе группового членства в Active Directory.

На рынке существует несколько платформ для построения дашбордов мониторинга. Рассмотрим двух ключевых игроков с точки зрения реалий российского рынка.

Grafana — открытая платформа визуализации данных, разрабатываемая с 2014 года. Она стала стандартом визуализации де-факто в мониторинге и DevOps-среде: Grafana-дашборды используются в организациях по всему миру для контроля всего — от одиночных серверов до распределенных систем с тысячами микросервисов.

Ключевые возможности Grafana: богатая экосистема плагинов для подключения источников данных (Prometheus, InfluxDB, Elasticsearch, PostgreSQL, ClickHouse и десятки других), гибкая система шаблонизации, алертинг с интеграциями в популярные каналы уведомлений, возможность создавать дашборды программно через API.

Как создать дашборд в Grafana? Этот вопрос хорошо описан в документации: настройка дашборда в Grafana выполняется через веб-интерфейс, тысячи готовых шаблонов доступны в открытых репозиториях. Вместе с тем у Grafana есть ограничения, актуальные для российских организаций. Grafana OSS (бесплатная версия) не имеет корпоративных функций безопасности: управления политиками паролей, журналов аудита, гибкой ролевой модели «из коробки». Grafana Enterprise с расширенным функционалом в настоящее время недоступна для приобретения в России.

Кроме того, Grafana отсутствует в реестре отечественного программного обеспечения и не имеет сертификации ФСТЭК. Это значит, что для значительной части российского рынка (госсектора, банков, промышленных предприятий) она фактически исключена из официального списка доступного и рекомендуемого ПО.

«Графиня» — платформа визуализации данных, разработанная «Лабораторией Числитель». Продукт создавался с нуля, без использования кодовой базы Grafana, и в декабре 2025 года был включен в реестр российского программного обеспечения.

С точки зрения архитектуры «Графиня» воспроизводит ключевые концепции, знакомые пользователям Grafana: дашборды (в терминологии продукта — «витрины данных»), источники данных через плагины, переменные, трансформации, плейлисты. Поддерживаемые источники данных: Zabbix/"Пульт", Prometheus, VictoriaMetrics, PostgreSQL, CSV, JSON, GitLab, Elasticsearch, ClickHouse.

Важная особенность — встроенные функции enterprise и безопасности: политики паролей, защита от брутфорса, журналы аудита, интеграция с LDAP и SAML, кеширование и прогнозирование. Это критически важно для организаций, проходящих аттестацию или эксплуатирующих системы в контуре с повышенными требованиями к ИБ. В базовой комплектации Grafana OSS ничего из перечисленного нет.

Среди технических возможностей, выделяющих «Графиню» на фоне Grafana:

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

— Прогнозирование — возможность налету получить на графике прогноз поведения той или иной метрики.

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

— Встроенная сервисно-ресурсная модель для Zabbix/"Пульта" — динамичная замена статичным схемам на базе Flowchart-плагинов.

Также в платформе предусмотрен функционал импорта дашбордов из Grafana. Дашборд экспортируется в формате JSON, загружается в «Графиню», а система автоматически выполняет маппинг источников данных и визуализаций. Это снижает трудозатраты команд при переходе и упрощает миграцию накопленных дашбордов.

В апреле 2026 года разработчик подал заявку на сертификацию ФСТЭК по 4-му уровню доверия. Получение сертификата для продукта «Графиня» запланировано до конца 2026 года. Для организаций, которым важна работа в сертифицированных контурах, это существенный аргумент в пользу платформы.

В части функционала создания дашбордов оба продукта предоставляют схожий UX: источник данных —> запрос —> тип визуализации —> сохранение. Метрики CPU, состояние контейнеров, экспорт и импорт данных — все это одинаково доступно в обеих системах.

Ключевое отличие «Графини» — наличие в реестре российского ПО, встроенные функции enterprise и безопасности «из коробки», техническая поддержка вендора и прозрачный дорожный план развития продукта. Для задач, где важен отчет перед регулятором или контролируемое импортозамещение, это решающие факторы.

Практика внедрения дашбордов мониторинга позволяет выявить несколько распространенных ошибок.

1. Перегрузка данными.

Дашборд с 40 панелями, каждая из которых обновляется каждые 5 секунд, создает огромную нагрузку на источники данных и затрудняет восприятие. Разумный подход: один дашборд — одна задача; для разных сценариев — отдельные дашборды.

1. Отсутствие контекста.

Метрика без базовой линии бессмысленна. Если CPU сейчас 75% — это много или мало? Добавляйте на дашборд историческое сравнение: недельный тренд, среднее за прошлый месяц.

1. Отказ от переменных.

Создавать отдельный дашборд для каждого сервера — крайне неэффективно. Шаблонизация через переменные позволяет обслуживать сотни объектов с помощью одного дашборда.

1. Игнорирование ролевого доступа.

Открытый доступ ко всем дашбордам — риск утечки чувствительных данных об инфраструктуре. Настраивайте роли с самого начала.

1. Отсутствие аннотаций и тегов.

Теги помогают группировать дашборды по назначению, приложению или среде (prod / dev / staging). Аннотации позволяют наносить на графики маркеры деплоев и инцидентов — это критически важно при анализе временных корреляций.

Система дашбордов для мониторинга ИТ-инфраструктуры — это ключевой инструмент, который помогает системе корректно работать и развивается вместе с инфраструктурой. Ее ценность определяется тем, насколько точно она отражает реальное состояние систем и насколько быстро позволяет команде реагировать на отклонения.

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

В качестве инструментов рынок предлагает как международную платформу Grafana с ее богатой экосистемой, так и российскую альтернативу — «Графиню» от «Лаборатории Числитель», внесенную в реестр российского ПО и обеспечивающую полный спектр корпоративных функций безопасности.

Для организаций, работающих в условиях импортозамещения или планирующих прохождение аттестации, «Графиня» представляет прагматичный выбор. Дашборд для ИТ-инфраструктуры, построенный на российской платформе, закрывает как технические требования, так и регуляторные. При этом существующие Grafana-дашборды можно будет легко перенести в «Графиню», что снизит стоимость перехода.

Что показывать на дашборде мониторинга серверов?

Базовый набор метрик — загрузка CPU, использование оперативной памяти, дисковый ввод-вывод, свободное место на диске и load average. Динамику во времени удобно смотреть на графиках временных рядов, текущие значения — на индикаторах Gauge и Stat. Для сравнения нескольких серверов подходит таблица, а светофор статусов помогает за секунду понять, всё ли в порядке.

Как работают переменные в дашбордах?

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

Чем отличается создание дашборда в Grafana и «Графине»?

Сам процесс одинаковый: подключаете источник данных, для каждой панели пишете запрос (PromQL, SQL или через визуальный конструктор) и выбираете тип визуализации. Разница в остальном. «Графиня» входит в реестр российского ПО, в ней из коробки есть парольные политики, защита от перебора паролей, журнал аудита и интеграция с LDAP и SAML, а также кеширование данных и прогноз метрик на графике. В базовой Grafana OSS этих функций безопасности нет.

Можно ли перенести дашборды из Grafana в «Графиню»?

Да. Дашборд экспортируют из Grafana в формате JSON и загружают в «Графиню». Система сама сопоставляет источники данных и типы визуализаций, поэтому на миграцию уходит заметно меньше времени.