Многие российские компании по разным причинам (импортозамещение, требования регуляторов к объектам КИИ, отсутствие поддержки, недоступность платных функций, безопасность и прочее) не могут использовать open-source-инструменты.

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

«Лаборатория Числитель» с 2019 года развивает три продукта: «Штурвал» (централизованное управление Kubernetes-кластерами), «Нимбиус» (частные и гибридные облака) и «Пульт» (система мониторинга на базе Zabbix). «Графиня» родилась как модуль визуализации для «Пульта», однако интерес со стороны рынка оказался настолько высоким, что разработчики решили вывести ее в самостоятельный продукт с собственной стратегией развития.

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

Зачем мониторингу отдельная визуализация

Чтобы понять место «Графини» на рынке, стоит разобраться, почему визуализация данных мониторинга вообще заслуживает быть самостоятельным продуктом. Система мониторинга решает целый спектр задач: собирает данные, обнаруживает и предотвращает проблемы, оповещает о них, также на ней — визуализация, отчётность, интеграция и автоматизация. Однако если спросить обычного потребителя мониторинга, не инженера, который настраивает систему, а того, кто ею пользуется, то выяснится, что большинство взаимодействует лишь с двумя вещами — оповещениями и визуализацией. Более того, нередко пользователи, отвечая на вопрос о наличии системы мониторинга, называют именно Grafana, хотя она обеспечивает исключительно отображение данных, а не весь процесс мониторинга.

При этом разные категории потребителей предъявляют к визуализации принципиально различающиеся требования. Дежурной смене нужны данные в реальном времени и единое окно, агрегирующее информацию из нескольких систем. Службе эксплуатации требуются фильтры, выборки и глубокая детализация — возможность «провалиться» от уровня сервиса до состояния конкретного интерфейса или процессора. Разработчикам и DevOps-инженерам важна скорость развёртывания, чтобы быстро создать визуализацию, проверить гипотезу и двигаться дальше. Руководителям и владельцам информационных систем нужна агрегация данных за длительные периоды, аналитика и кастомизация с изоляцией данных. А бизнес зачастую просто хочет, чтобы «было хорошо и красиво», — и при этом в каждой новой компании представление о красоте оказывается своим.

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

Написано с нуля

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

Стоит отметить, что на мировом рынке формируется альтернативное направление: проект Perses, развиваемый под эгидой фонда CNCF при участии Red Hat, предлагает cloud-native-подход к визуализации данных мониторинга. Perses существует с 2022 года и ориентирован на преодоление архитектурных ограничений Grafana, прежде всего — её монолитности. Однако для российского рынка, где ключевым требованием является присутствие в реестре отечественного ПО и наличие локальной поддержки, Perses не может рассматриваться как альтернатива «Графине».

Важно также провести границу между «Графиней» и BI-системами. На первый взгляд, продукты класса BI — такие как Superset, Redash, Tableau и их аналоги — решают схожие задачи: подключают источники данных и строят визуализации. Однако BI-системы ориентированы на бизнес-аналитику и работу с большими массивами исторических данных, тогда как Grafana и «Графиня» выросли из потребностей оперативного мониторинга в реальном времени, где важны интерактивность, скорость создания дашбордов и возможность автоматизации через подход «инфраструктура как код» (IaaC). Развернуть «Графиню», подключить источник данных и создать первый рабочий дашборд можно буквально за пять минут — немногие BI-системы способны обеспечить сопоставимую скорость старта.

Архитектура и работа с плагинами

Бэкенд-ориентированный подход

Ключевое архитектурное отличие «Графини» от Grafana заключается в подходе к работе с плагинами источников данных. В Grafana каждый плагин включает в себя и фронтенд, и бэкенд, причём фронтенд-часть должна быть написана на React с использованием собственных библиотек Grafana. Это существенно повышает порог входа для разработчиков плагинов.

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

Развёртывание плагинов основывается на контейнерной архитектуре. Чтобы подключить новый, достаточно добавить соответствующий контейнер в docker-compose, а затем в пользовательском интерфейсе указать ссылку на контейнер по HTTP(S). После этого выполняется настройка источника данных через привычные поля конфигурации. При этом плагины автоматически строят формы настройки на основе контрактов — внутреннего API, описывающего параметры подключения, что обеспечивает единообразие интерфейса конфигурации для всех источников данных.

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

Хранение данных и принцип работы на лету

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

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

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

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

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

Безопасность на уровне архитектуры

Бэкенд-ориентированная архитектура даёт ещё одно важное преимущество в части информационной безопасности. Пользователи могут настроить разграничение доступа таким образом, что к закрытому источнику данных будет иметь доступ только плагин, а пользовательский интерфейс напрямую к источнику обращаться не будет. Связь между плагином и бэкендом можно настроить отдельно. Такая схема добавляет дополнительный уровень защиты при работе с чувствительными данными.

Развёртывание и инсталляция

Установка «Графини» выполняется целиком в Docker-контейнерах и описана в документации на портале продукта. Для запуска достаточно создать папку, разместить в ней три конфигурационных файла (docker-compose и два файла конфигурации), подключиться к реестру контейнеров и выполнить команду docker-compose up. По умолчанию платформа запускается на 80-м порте, однако порт легко изменить в конфигурации. Весь процесс от скачивания контейнеров до открытия интерфейса в браузере занимает считаные минуты.

Для получения доступа к реестру контейнеров «Лаборатории Числитель» необходимо обратиться к разработчикам — на данный момент выдаются индивидуальные учётные данные, что позволяет контролировать распространение продукта на этапе раннего внедрения.

В планах — интеграция с платформой «Штурвал» (Kubernetes-платформа «Лаборатории Числитель»), что позволит разворачивать и масштабировать «Графиню» в Kubernetes-кластерах. Хотя на текущий момент основной сценарий — классическое развёртывание в Docker, архитектура продукта не создаёт принципиальных препятствий для работы в оркестрированных контейнерных средах. Архитектурно система изначально допускает горизонтальное масштабирование отдельных компонентов, включая плагины и проксирующие узлы, а для развёртывания в Kubernetes подготовлены Helm-чарты. При этом команда пока не публикует формально подтверждённые лимиты по числу пользователей, источникам данных и объёму событийной нагрузки: специализированные нагрузочные испытания ещё не оформлены в виде публичных характеристик.

Источники данных

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

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

Также реализована поддержка Victoria Metrics и Prometheus, что позволяет подключать системы мониторинга сервисов и базы данных временных рядов. Для запросов к этим источникам используется язык PromQL (Prometheus Query Language), который указывается в настройках подключения. Помимо визуального конструктора запросов, поддерживается режим написания кода, в котором пользователь может вручную составлять PromQL-выражения. Администратор имеет возможность запретить режим кода для конкретного источника данных, если этого требует политика безопасности или эксплуатации.

Для работы с реляционными данными создан плагин PostgreSQL, совместимый с PostgreSQL версии 9 и выше, Postgres Pro версии 13 и выше, а также с СУБД Pangolin DB версии 4 и выше. В режиме кода поддерживается полноценный SQL, включая произвольные запросы с джойнами и фильтрами. Для защиты от избыточных выборок предусмотрен настраиваемый лимит строк на уровне источника данных. Администратор может задать максимальное количество возвращаемых записей или снять ограничение, установив значение «0».

Помимо этого, поддерживаются универсальные форматы данных: JSON и CSV. При этом работа с ними организована гибко. Можно загрузить файл напрямую, указать ссылку на динамический справочник, доступный по HTTP или HTTPS (с возможностью настройки сертификатов и проверки подлинности), положить файл в файловую систему на сервере плагина и указать путь к нему, вставить содержимое непосредственно в интерфейсе или выбрать файл через диалог загрузки. При загрузке через интерфейс файл кодируется и сохраняется внутри системы. Разделитель полей в CSV также является настраиваемым параметром. В последнем релизе также появились плагины для GitLab API, Elasticsearch и СУБД ClickHouse.

Для каждого источника данных предусмотрены различные режимы настройки запросов — визуальный конструктор, режим написания кода и работа через JSON. Конструктор рассчитан на пользователей, не желающих погружаться в синтаксис запросов, поскольку для получения данных достаточно заполнить выпадающие списки и параметры. Режим кода предназначен для продвинутых пользователей и позволяет, например, написать произвольный SQL-запрос для PostgreSQL или PromQL-запрос для Prometheus и Victoria Metrics. Разработчики планируют добавить автоподсказки и автодополнение в режиме кода, что позволит ускорить написание запросов и снизить количество ошибок — по аналогии с тем, как это реализовано в Grafana при работе с Prometheus и Victoria Metrics. Также планируется постепенно наращивать количество поддерживаемых плагинов, начав с наиболее востребованных интеграций и расширяя их число по мере получения обратной связи от пользователей.

Визуализация данных

Витрины данных и виджеты

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

Интерфейс редактирования виджета разделён на три области: зону предварительного просмотра визуализации, область настройки запросов к источникам данных и панель параметров отображения. В параметрах отображения доступны переопределения — возможность задать для конкретного столбца таблицы или серии на графике индивидуальные настройки, а именно единицы измерения (байты, проценты, секунды), способ отображения, цветовую схему и прочее. Это особенно полезно при работе с таблицами, где каждый столбец может требовать собственного формата представления.

Для удобства создания однотипных виджетов реализована функция дублирования. Любой виджет можно клонировать в один клик, после чего изменить тип визуализации или параметры запроса. Это значительно ускоряет наполнение витрины данных.

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

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

Реализована работа с переменными и трансформация данных (функциональность находится в стадии активной разработки). Также в платформе предусмотрены контекстные переходы (drill-down) — от общей картины к конкретным метрикам.

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

Организация витрины: строки и блоки

Для структурирования содержимого витрины данных реализован механизм строк (rows) — сворачиваемых блоков, объединяющих группу виджетов. При сворачивании блока запросы к источникам данных для входящих в него виджетов прекращаются, что даёт ощутимый прирост производительности на тяжёлых витринах с большим количеством виджетов. Пользователь видит вверху самую важную информацию в развёрнутом виде, а при необходимости раскрывает дополнительные блоки, подгружая данные по требованию. Виджеты можно перемещать между строками. В ближайших релизах планируется добавить возможность перетаскивания виджетов методом drag-and-drop, а также шаблонирование строк (templating) — автоматическое клонирование блока для каждого значения переменной, например для каждого сетевого интерфейса сервера. Иерархия папок в витринах появилась в релизе 2026H1.

Владельцы витрин данных

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

Выгрузка данных

Платформа поддерживает выгрузку данных из виджетов в формат CSV, а также применение фильтров и переходов между витринами.

Ресурсно-сервисная модель

Отдельно стоит отметить модуль ресурсно-сервисной модели (РСМ). Это не просто виджет, а полноценный интерактивный модуль, позволяющий мгновенно диагностировать состояние ИТ-сервисов систем Zabbix или «Пульт». Модуль отображает древовидный граф всех сущностей и их взаимосвязей. Пользователь может нажимать на любой узел графа, и при этом срабатывают заранее настроенные сценарии, которые обновляют информацию на соседних виджетах витрины. Наглядность сложных связей и интерактивность делают этот инструмент удобным для оперативной работы с инцидентами и анализа зависимостей между компонентами инфраструктуры.

Управление доступом

Разработчики реализовали гибкую ролевую модель с тремя уровнями: наблюдатель, оператор и администратор. Над ними существует четвёртая роль — суперадминистратор, аналогичная Super Admin в Grafana, обладающая полными правами управления всей платформой, включая настройку плагинов и управление организациями. Концепция «Организаций» позволяет создавать независимые пространства, каждое из которых обладает собственным набором пользователей, витрин данных и источников данных. Это удобно для компаний с несколькими подразделениями или для сервис-провайдеров, обслуживающих разных клиентов.

Наблюдатель имеет доступ к витринам данных только на просмотр. Оператор может создавать и редактировать собственные витрины. Администратор организации также получает возможность управлять источниками данных, добавлять и деактивировать пользователей. При попытке деактивировать пользователя, состоящего в нескольких организациях, система предупреждает, что операция доступна только суперадминистратору. Один и тот же пользователь может входить в несколько организаций под разными ролями — например, быть наблюдателем в сетевом отделе и оператором в отделе DevOps. Переключение между организациями выполняется через интерфейсный переключатель.

На текущий момент удаление пользователей не реализовано — доступна только деактивация. В релизе 2026H1 разработчики планируют добавить возможность полного удаления с мастером, который предложит перенести владение витринами данных удалённого пользователя на другого пользователя или стереть их.

Для интеграции с корпоративными системами идентификации реализована поддержка SSO, в том числе через Blitz Identity Provider с использованием протокола SAML 2.0. В стадии тестирования находится поддержка LDAP. Поступают также запросы на реализацию OpenID Connect (OIDC), что рассматривается как перспективное направление развития. Стоит упомянуть, что SSO и LDAP в Grafana доступны только в платной Enterprise-версии, которую в России официально приобрести невозможно.

В ближайшем релизе разработчики также планируют расширить набор функций безопасности. В частности, появятся отдельный раздел безопасности, автоматическая блокировка учётных записей при длительном отсутствии входа, а также поддержка второго фактора через интеграцию с внешними системами идентификации. Эти изменения напрямую связаны с подготовкой продукта к сертификации ФСТЭК и запросами со стороны заказчиков с повышенными требованиями к защите доступа.

Осознанное отсутствие алертинга

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

Тем не менее, с учётом высокого спроса, добавление функционала алертинга и OnCall запланировано на II половину 2026 г. — в релизе 2026H2. Уже сейчас команда прорабатывает сценарии, при которых в платформе появится поддержка правил и пороговых значений для метрик с доставкой уведомлений по электронной почте, в мессенджеры и через webhook-интеграции. Кроме того, разработчики рассматривают более широкий класс задач дежурного реагирования — создание аналога Grafana OnCall с поддержкой инцидентов, эскалаций и графиков дежурств.

Преимущества перед Grafana

Включение в реестры и соответствие требованиям

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

Enterprise-функции без Enterprise-цены

Как уже говорилось выше, ряд возможностей, доступных в Grafana только в коммерческой Enterprise-версии, в «Графине» реализованы в базовой поставке. К ним относятся поддержка SSO и LDAP (в стадии финального тестирования), функции безопасности, а также расширенные механизмы управления доступом. С учётом того, что Enterprise-версию Grafana в России сейчас приобрести нельзя, а даже при наличии ранее купленных лицензий техническую поддержку получить невозможно, «Графиня» закрывает эту потребность полностью.

Стабильность при обновлениях

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

Эта проблема в случае Grafana носит системный характер. Разработчик «Графини» приводит пример из собственной практики, когда при внедрении системы мониторинга на базе определённой версии Grafana к моменту сдачи проекта эта версия перестала быть актуальной, поэтому после обновления всё пришлось переделывать практически с нуля. То есть инженер полгода строит систему визуализации, согласовывает её с руководством, вводит в эксплуатацию, а после обновления Grafana дашборды «разлетаются», трансформации перестают работать, плагины визуализации больше не поддерживаются. Особенно болезненно это ощущается, когда в дашборды смотрит руководство. Grafana Labs проводит агрессивную политику выпуска версий, фактически ориентируясь на своё облачное решение Grafana Cloud, а open-source-версия остаётся «осколком» облака, где всё сделано так, как удобно разработчикам, а не пользователям.

Поддержка плагинов от первого лица

В экосистеме Grafana подавляющее большинство плагинов написано пользовательским сообществом. Соответственно, поддержка и обновление этих плагинов целиком зависит от энтузиазма авторов. Плагин может быть заброшен в любой момент, и пользователь, построивший на нём критически важную визуализацию, окажется в тупике. Приведём показательный пример. Плагин Flowcharting для отрисовки ресурсно-сервисных моделей, популярный в проектах мониторинга, в какой-то момент перестал поддерживаться, оставив пользователей без альтернативы.

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

Производительность под нагрузкой

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

Миграция с Grafana

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

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

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

Интерфейс и локализация

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

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

Платформа предоставляет открытый API для интеграции с внешними системами, а модульная архитектура позволяет расширять функциональность путём создания собственных модулей и их интеграции в платформу.

Текущий статус и планы развития

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

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

Разработчики не исключают появления в будущем разделения на Community- и Enterprise-редакции, где бесплатная версия будет предоставлять базовую функциональность, а платная — полный набор возможностей, необходимых корпоративным заказчикам, включая мультитенантность, интеграцию с каталогами и формальное соответствие требованиям импортозамещения. При этом внутри команды уже обсуждается более конкретный ознакомительный контур Community-редакции — например, одна организация и минимальный набор учётных записей по ролям.

Резюмируем ближайшие планы команды разработчиков «Графини»:

• доведение до релиза поддержки LDAP и проработка OpenID Connect;
• добавление функционала алертинга;
• добавление функционала OnCall;
• реализация полноценного импорта и экспорта витрин в JSON;
• добавление drag-and-drop для перетаскивания виджетов;
• шаблонирование строк (templating);
• поддержка произвольных временных диапазонов и возможность выделения области на графике для зуммирования;
• стартовая страница администратора с карточками статуса — количество пользователей, источников данных, индикаторы их доступности;
• исследование возможностей прогнозирования и построения трендов на основе визуализируемых данных;
• получение сертификации ФСТЭК по 4-му уровню доверия.

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