Grafana поддерживает все востребованные типы визуализации данных и предлагает несколько вариантов работы в embedded-режиме. Расскажем, как прошли путь от серии экспериментов до рабочей конфигурации интеграции в отдельный продукт — с полным управлением интерфейсом и пользовательским опытом.
О проекте
К нам обратился производитель оборудования для геотехнического мониторинга, которое используют для контроля состояния зданий и сооружений. Требовалось разработать систему, способную в режиме реального времени визуализировать миллионы измерений, поступающих с датчиков.
Выбор стратегии: ТЗ или эксперимент
Первоначальный запрос был подготовить техническое задание на разработку платформы для конфигурирования витрин данных через пользовательский интерфейс. В большинстве случаев это верный подход, но в процессе обсуждения выяснилось, что у клиента уже есть гипотеза — использование Grafana. А это решение сразу ставит перед фундаментальным выбором.
Как встроить Grafana-дашборд в свое веб-приложение?
Есть два способа, и выбор зависит от того, насколько важен контроль над интерфейсом.
Способ 1 — iframe в embedded-режиме. Самый быстрый путь: дашборд вставляется в приложение через iframe по внешней ссылке. Начиная с Grafana 9.1 поддерживается аутентификация через JWT-токен сервисного аккаунта — пользователь вашего приложения не видит экран логина Grafana. Фронтенд может программно управлять дашбордом через HTTP API: получить JSON-дескриптор, изменить расположение и размер панелей, тип визуализации, источники данных — и записать обновленный JSON обратно. Grafana отрисует результат сама. Это разумный выбор, когда нужно быстро показать графики внутри своего интерфейса без разработки визуализаций с нуля. Ограничение — внешний вид и поведение графиков определяет Grafana, а не вы.
Способ 2 — Grafana API + собственная отрисовка. Grafana используется только как источник данных: приложение забирает JSON с метриками через API и рисует графики самостоятельно — на D3.js, Chart.js или другой подобной библиотеке. Это даёт полный контроль над дизайном, поведением и аутентификацией, позволяет бесшовно интегрировать графики в интерфейс приложения. Но вся логика визуализации, фильтрации и обновления данных ложится на вашу команду. Подход оправдан, когда iframe-вариант не покрывает требования к UX или когда графики должны взаимодействовать с остальными элементами приложения.
Для задач проекта полный контроль над UX не требовался, поэтому первый вариант выглядел оптимальнее. Но была проблема: до нас решение пыталась реализовать другая команда — и столкнулась с ограничениями, которые не смогла обойти. Встал вопрос: документация платформы действительно описывает рабочий путь, или вводит в заблуждение?
Proof of Concept: три вопроса, которые определили архитектуру
Мы решили что нужно пойти другим путем — сформировать требования и проверить их через серию экспериментов, направленных на выявление ограничений платформы и подтверждение архитектурных допущений. Такой подход называет доказательство концепции (англ. Proof-of-concept, PoC), он дает результат, на основе которого уже можно проектировать архитектуру решения. На какие вопросы требовалось дать точные ответы:
Можно ли полностью скрыть интерфейс Grafana при встраивании дашборда через iframe?
Да. В ходе исследования мы подтвердили, что Grafana позволяет отображать дашборд по внешней ссылке полностью без интерактивных элементов — включая меню с тремя точками, через которое можно перейти в нативный интерфейс. При встраивании дашборда целиком в режиме киоска элементы управления Grafana отсутствуют. При встраивании отдельных панелей меню с тремя точками появляется, но под учетной записью Viewer оно неактивно — переход в Grafana с полным доступом невозможен. Документация допускает оба сценария, однако для нас было принципиально проверить это на практике: заказчику требовался защищенный режим, исключающий любой выход пользователя за пределы встроенного представления.
Справится ли Grafana с отображением большого объема данных на нескольких графиках одновременно?
Справится. В ходе нагрузочного тестирования мы проверили два сценария.
Синтетический тест: 80 датчиков (по ~200 000 измерений в месяц каждый), разнесенных по 5 дашбордам с обновлением каждые 5 секунд. Grafana отобразила все графики в реальном времени без лагов, нагрузка на CPU и RAM выросла примерно на 5%.
Тест на реальных данных: 5 панелей на одном дашборде, от 187 до 342 тысяч записей на график. При локальном подключении БД все графики строятся мгновенно (до 2 секунд). При подключении к удаленным серверам MySQL возникала нестабильность — часть графиков периодически не загружалась из-за ограничений пула соединений на стороне БД.
Вывод: узкое место — не Grafana, а конфигурация и доступность серверов баз данных. При корректной настройке пула соединений MySQL проблема устраняется.
Что будет, если Grafana ограничит доступ для пользователей из России?
Ничего. У Grafana открытый исходный код. Мы разворачиваем self-hosted инстанс LTS-версии на серверах заказчика. Такой инстанс не обращается к серверам Grafana Labs, не требует облачной авторизации и не зависит от доступности внешних сервисов вендора. Даже если Grafana Labs полностью прекратит работу с российскими пользователями — заблокирует облачную платформу, закроет доступ к репозиториям обновлений — уже развернутая система продолжит работать без ограничений. Обновления безопасности для OSS-версии доступны через открытые репозитории и зеркала, поддерживаемые сообществом. Выбор LTS-версии дополнительно снижает риск: она получает исправления дольше, чем обычные релизы, и не требует частых обновлений.
Административный интерфейс для управления проектом, объектами и доступами
От PoC к MVP: как мы выстроили разработку
По итогам экспериментов мы убедились, что встраивание Grafana через iframe работает. Следующий шаг — спроектировать минимальную жизнеспособную версию продукта (MVP). И здесь мы сознательно отказались от классического этапа аналитики.
Почему мы не писали техническое задание? Проект не отличался запутанными бизнес-процессами, сложной ролевой моделью или многоуровневой логикой согласований. Функциональные требования сводились к тому, что пользователь настраивает зоны на экране, выбирает датчик и тип графика — система показывает данные в реальном времени. Вся реальная сложность лежала в технической плоскости.
В таких условиях классическое ТЗ формализовало бы то, что и так понятно, а главные риски оставило бы непроверенными. Вместо этого мы сфокусировались на нефункциональных требованиях и техническом решении.
Экспертизу предметной области мы получали прямо на встречах. Заказчик детально объяснял, как устроен каждый тип датчика, какие данные он записывает, какие единицы измерения и коэффициенты пересчета используются. По итогам встреч ведущий разработчик готовил документ, который одновременно описывал архитектуру, способ интеграции и оценку трудоемкости.
Архитектура решения
Центральное архитектурное решение проекта — использование Grafana не как готового дашборда, а как встраиваемого движка визуализации. Инженеры не заходят в интерфейс Grafana напрямую. Они работают в приложении «Интертех», а Grafana рендерит графики «под капотом». Для этого наши backend-инженеры разработали три компонента: кастомный плагин Grafana, proxy-сервер и механизм авторизации.
Кастомный плагин Grafana
Стандартный интерфейс Grafana не подходил для задач клиента. Пользователю не нужно видеть десятки настроек панели — ему нужно выбрать датчик, указать показатель и получить график. Поэтому мы написали собственный плагин, который управляет дашбордами через API Grafana, но предоставляет упрощенный интерфейс, без возможности попасть на саму платформу.
Плагин решает несколько задач: добавление и удаление графиков в реальном времени через WebSocket, управление расположением панелей на дашборде, экспорт данных в CSV, переключение между табличным и графическим представлением.
Визуальный конструктор графиков поверх SQL
За каждым графиком в системе стоит SQL-запрос к базе данных клиента. Но пользователь не видит SQL и не должен его знать. Вместо этого он работает с визуальным конструктором: выбирает датчик, добавляет показатели (угол наклона, смещение, температуру), настраивает фильтрацию и агрегацию. Система собирает из этого корректный запрос и передает его Grafana.
Графики датчиков в реальном времени
Основная сложность — в валидации. Разные типы графиков принимают разные параметры, и система должна отсекать некорректные комбинации до отправки запроса. У каждого типа графика — свой набор настроек. Например, масштабирование: для графика типа «Временной ряд» параметры задаются отдельно для каждой оси (если используется несколько осей), для «Гистограммы» — всегда только для одной оси, а круговая диаграмма такой настройки не поддерживает вовсе, поскольку у нее отсутствуют оси. Мы вынесли эти правила в отдельный слой валидации, чтобы пользователь получал ошибку в интерфейсе, а не пустой график.
Оптимизация под высокую нагрузку
Датчики фиксируют показания каждые 10 секунд, это более 200 000 измерений в месяц с каждого устройства. В сумме дашборд должен одновременно обрабатывать и отображать более 1 200 000 записей из разных источников, а также показывать данные в реальном времени по 80 датчикам. При этом система должна не просто показывать графики, а стабильно выдерживать такие объемы, не перегружая ни базу данных, ни браузер пользователя.
Чтобы не перегружать браузер мы реализовали режим группировки по интервалам: система берет, к примеру, пять записей, вычисляет среднее и выводит одну точку вместо пяти. Это сокращает число точек на графике в разы, при этом сохраняет информативность.
Для проверки на реальных объемах клиент предоставил SSH-доступ к серверу и запустил запись данных на несколько недель. Мы тестировали графики на реальных данных и корректировали запросы по результатам.
Дизайн интерфейса: от прототипа к продуктовому UI
На старте проекта требований к дизайну не было — заказчика устраивало любое работающее решение. Мы выбрали готовую UI-библиотеку Preline задали цветовую палитру в фирменном стиле заказчика и собрали трехпанельный интерфейс на основе базовых пожеланий: навигация, список датчиков, область с графиками. Этого хватило, чтобы выпустить прототип в продакшн для внутреннего использования.
После того как прототип подтвердил жизнеспособность решения, встал вопрос о полноценном интерфейсе. К этому моменту появились новые требования: управление датчиками, сложные древовидные структуры объектов, система алертов, многоуровневые модальные окна. Эти сценарии нужно было прорабатывать предметно: навигацию по деревьям, логику вложенных состояний, поведение алертов. Компоненты Preline использовались как основа, но кастомизировались под конкретные задачи и подтягивались к актуальным UX-практикам.
CI/CD с первого дня: зачем мы это делали
На проекте мы сразу установили правило: все, что сделано, можно посмотреть по прямой ссылке. Для этого мы настроили тестовое окружение и CI/CD в первые дни работы.
Инфраструктура проекта состоит из трех приложений: фронтенд, бэкенд с интегрированным proxy-сервером и кастомный плагин. Для каждого из них мы настроили отдельный пайплайн развертывания. Любое изменение в коде автоматически попадает на тестовый стенд.
Зачем это нужно в контексте проекта? Перед нами визуальный продукт. Его ценность в том, как выглядят графики, как работает навигация, как реагирует интерфейс на реальные данные. Показать это в документе или на скриншоте невозможно. Клиент должен зайти, протестировать, и сказать, что нравится, а что нужно переделать.
Именно так и происходило. На еженедельных встречах разработчик открывал стенд прямо в браузере, а клиент видел не макеты, а работающий продукт и давал комментарии. Это кардинально другой уровень обратной связи по сравнению с обсуждением прототипов.
На CI/CD мы потратили около 10 часов в начале проекта. Эти часы окупились многократно: мы не тратили время на «сборку демо перед встречей» и не теряли контекст между итерациями.
Просмотр датчиков объекта с группировкой по типам измерений
Дашборд объекта с несколькими типами визуализации данных
Результат
Система успешно запущена в эксплуатацию. Клиент подключает реальные объекты, настраивает датчики и использует платформу как рабочий инструмент.
Что конкретно получилось:
- Два интерфейса: административный и пользовательский, с единой системой авторизации и разграничением ролей;
- Визуальный конструктор графиков, который собирает SQL-запросы за пользователя;
- Обработка более 1 000 000 измерений через группировку по интервалам;
- Кастомный плагин Grafana с управлением через WebSocket;
- CI/CD для трех приложений — клиент видит результат на каждом этапе;
- Семафор для дерева датчиков для мониторинга значений показателей в real-time.
Проект продолжает развиваться и поэтапно получать функциональные обновления.
Заключение
Главный урок проекта: когда основные риски реализации лежат в технической интеграции, а не в бизнес-логике — начинать нужно не с ТЗ, а с проверки работоспособности решения. Серия PoC-экспериментов дала нам ответы, которые невозможно получить из документации. Дальше все выстроилось естественно: архитектура опиралась на проверенные допущения, дизайн развивался вместе с продуктом, а CI/CD обеспечивал непрерывную обратную связь с заказчиком.
Результат — рабочая платформа, которая визуализирует данные с сотен инженерных датчиков в реальном времени, с embedded Grafana под капотом и полным контролем над интерфейсом.
Если вашему бизнесу нужна интеграция Grafana для визуализации больших объемов данных в режиме реального времени — оставьте заявку, и мы разберемся, как это лучше реализовать.
