Хабр, привет! На связи Дима Унтила, product owner «Пульта» и «Графини», и Паша Мирошин, ведущий разработчик в «Лаборатории Числитель».  

Несколько недель назад мы объявили о выпуске «Графини» — первого на рынке аналога Open-Source-платформы Grafana. И тут прорвало всех: столько критики, предложений и шуток мы не получали никогда ? Кто пропустил — велком сюда.

За время существования Grafana собрала вокруг себя большое мировое комьюнити. Она бесплатная, развиваемая, популярная. И первый очевидный вопрос, который мы получили от сообщества: зачем разрабатывать аналог? Только ради регистрации в реестре?

Отвечаем:

? Причина №1: да, ради регистрации в реестре. Многие вынуждены отказываться от Open Source из-за требований регуляторов. А полноценных аналогов нет.

? Причина №2: многолетий болезненный опыт использования Grafana. При всех плюсах, которыми она обладает, есть и один существенный минус — нестабильность работы ее компонентов при обновлениях. Если вспомнить инженерное прошлое, то сколько раз приходилось переделывать сложные дашборды после масштабного обновления — просто не сосчитать.

? Причина №3: мы хотим использовать «Графиню» не только как самостоятельный продукт, но на ее основе расширять функционал «Пульта» (наша система мониторинга на основе Zabbix) и встраивать ее в другие собственные продукты («Штурвал» и «Нимбиус»).

? Причина №4: многие полезные фичи Grafana доступны только в платной версии (например, развитая ролёвка), а купить ее сейчас проблематично. 

Учитывая эти моменты, было решено не плодить очередной форк (ибо какой в этом смысл), а написать решение «с нуля», не только сделав его похожим на Grafana, но и улучшив.

Ниже рассказываем про архитектуру «Графини» и ее полезные фичи.

А что «под платьем»?

Архитектура решения состоит из нескольких компонентов:

• Ядро, в которое входит:

  o   Web UI — frontend-часть приложения, написанная на React;

  o   Backend — серверная часть для обслуживания фронта. Помимо стандартных API, она содержит в себе агрегатор запросов данных. Так как предполагается не такая высокая нагрузка на бэкенд, а в основном перенаправление и кеширование данных, то для простоты реализации мы выбрали NodeJS;

  o   База данных — хранилище всех настроек фронта, пользователей и запросов. Чтобы обеспечить гибкость и избежать нагрузки на базу данных, мы выбрали MongoDB.

• Плагины — различные плагины по предоставлению данных (data provider plugins). Каждый плагин поддерживает подключение к собственному типу источника данных, преобразовывает информацию в единый формат и имеет предусмотренные архитектурой ядра API для общения с ядром.

  

  Плагины по предоставлению данных из других систем располагаются в отдельных от ядра контейнерах и общаются по HTTP/HTTPS-протоколу с бэкендом «Графини». Такая архитектура позволяет разрабатывать плагины отдельно от самого ядра и писать их на любом языке программирования.

  В отличие от Grafana, мы решили облегчить жизнь разработчикам плагинов. Теперь им необязательно знать React и использовать UI kit, чтобы создавать формы для заполнения полей источников данных и конструкторы запросов в редакторе виджета. Для этого достаточно соблюсти JSON-контракт для автоматического построения полей.

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

Немного о ноу-хау

Многоуровневое кеширование

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

Как это работает:

1. Агрегация запросов на уровне виджета.
   Когда пользователь открывает витрину данных, фронтенд отправляет единый пакетный запрос на бэкенд, содержащий все необходимые подзапросы данных.

2. Кеширование на уровне ядра.
   Бэкенд проверяет каждый подзапрос в своем внутреннем кеше. Если данные актуальны, они сразу возвращаются, минуя дальнейшие обработки.

3. Группировка и оптимизация запросов к плагинам.
   Оставшиеся запросы автоматически группируются по целевым плагинам, чтобы минимизировать сетевые издержки. Например, если пять подзапросов требуют данных из одного источника, они объединяются в один HTTP-запрос к соответствующему плагину.

4. Двухуровневое кеширование на стороне плагина.
   Плагин, получив запрос, создает кеш запроса, через который собираются все новые данные по стратегии Read Through Cache. Дополнительно пользователь может включать и управлять кешем второго уровня, который реализован по принципу LRU с возможностью управлять TTL. Благодаря этому тяжелые запросы в источники данных могут быть оптимизированы, и в рамках одного даже долго исполняемого запроса пользователь получит консистентные данные.

Универсальные API-контракты

В отличие от Grafana, где разработчикам плагинов приходится создавать UI-компоненты на React и встраивать их в систему, мы пошли другим путем. Наш подход основан на едином JSON-контракте, который полностью описывает все необходимые поля для настройки источника данных и построения запросов.

Это значит, что плагину не нужно заботиться о верстке форм или интеграции с UI-фреймворками — система автоматически генерирует интерфейс на основе JSON-схемы. Достаточно лишь реализовать REST API, соответствующее нашему протоколу, и описать структуру данных в согласованном формате.

Почему это круто?

1. Разработка проще и быстрее.

• Не нужно изучать React или внутренние компоненты Grafana — достаточно описать поля в JSON и реализовать логику запросов к своему источнику данных.

• Можно писать плагины на любом языке (Python, Go, Java, C# и т. д.), так как общение происходит через HTTP/HTTPS.

2. Гибкость и независимость от UI.

• Если в будущем мы изменим дизайн системы или добавим новые типы полей, старые плагины продолжат работать — ведь их интерфейс определяется JSON-контрактом, а не встроенными компонентами.

• Плагины можно разрабатывать и тестировать изолированно, без необходимости разворачивать всю систему.

3. Безопасность и масштабируемость.

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

• Пользователи не имеют прямого доступа к плагинам — все запросы проходят через ядро системы, что снижает риски утечек данных.

Таким образом, наш подход упрощает жизнь разработчикам, ускоряет создание новых интеграций и делает систему более гибкой для будущих изменений. Все, что нужно для старта, — это REST API и правильно оформленный JSON-контракт.

А что еще?

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

• SAML-аутентификация — поддержка корпоративных стандартов безопасности для удобного входа через Identity Provider (Blitz, Okta и др.).

• Встраивание виджетов и витрин данных — возможность интегрировать отдельные графики или целые витрины данных в сторонние системы через API-токен, без необходимости полной аутентификации.

• Динамические переменные в запросах — гибкая подстановка параметров (например, временной диапазон или фильтры) прямо в запросах к данным, что упростит создание интерактивных отчетов.

У «Графини» еще нет своего сайта, она скромно ютится на странице «Пульта». Пока можете посмотреть видео с демо продукта, прошедшего на канале FIDELINA.

P. S. Всех будем рады видеть 10-11 сентября на конференции IT Elements — в первый день выступим с докладом про нашу разработку? А вообще, следите за новостями в нашем Telegram!