Grafana vs Dimension-UI
Grafana vs Dimension-UI

Недавно рассказывал про мониторинг истории активных сессий в базах данных Oracle, PostgreSQL, ClickHouse и MS SQL Server с использованием desktop-приложения Dimension-UI (link). В комментариях @KPSB92 задал вопрос о преимуществах/отличиях связки exporter Prometheus/Grafana и Dimension-UI, решил оформить ответ в эту небольшую статью.

Итак, возьмем для примера просмотр данных активных сессий в базе данных PostgreSQL и сравним визуализацию в Grafana и Dimension-UI. Посмотрим работу с интерфейсами обоих систем в динамике с помощью скринкастов.

Настройка окружения

Настроим связку PostgreSQL/Prometheus/Grafana на локальном ПК с использованием Docker для работы с данными истории активных сессий. Для этого скачаем проект PostgreSQL Active Session History Monitoring with Grafana с GitHub (создан на основе статьи Визуализация Active Session History в PostgreSQL — делаем просто и красиво) и запустим команду:

docker-compose up -d

Далее, настроим ручной запуск сбора данных истории активных сессий в специальную таблицу в БД PostgreSQL adm.pg_stat_activity_history с интервалом каждые 3 секунды.

После установки приложений и сбора данных заходим в интерфейс Grafana и проверим что данные по истории активных сессий записываются в Prometheus через Custom Exporter. В интерфейсе Home -> Drilldown -> Metrics в поле Quick search metrics введем строку active - и смотрим что данные в графиках отображаются (pg_stat_database_active_time_seconds_total, postgres_active_sessions_total и другие метрики).

В БД PostgreSQL проверим, что данные в adm.pg_stat_activity_history записываются. При необходимости - запустим эмуляцию нагрузки через pgbench.

pgbench -c 10 -j 2 -t 10000000 postgres

Проверим, что в интерфейсе Dashboards появилась ссылка на PostgreSQL Active Sessions History. У меня не получилось завести все одним импортом, поэтому пришлось вручную добавлять JSON файл dashboard-а через интерфейс Dashboards -> Кнопка New -> Import -> Upload dashboard JSON file - файл берем из проекта. Далее создаем подключение в БД вручную - см. раздел PostgreSQL Data Source Setup in Grafana указываем его подключением по умолчанию (должен появится тэг default), и правим ссылки на него в JSON файле - см. раздел Fixing Data Source in Dashboards. UID подключения можно узнать выбрав подключение к БД в интерфейсе Home -> Connections -> Data sources и посмотрев на URL http://localhost:3000/connections/datasources/edit/ef0xfrka0p8n4a - UID будет равен ef0xfrka0p8n4a.

Теперь приступим к настройке Dimension-UI. На клиетской станции необходимо установить Java не ниже 25 версии и загрузить Dimension-UI, указать в скрипте запуска run.bat/run.sh путь к установленной Java и далее приступить к настройке сбора данных - информация есть в статье Мониторинг истории активных сессий в базах данных. Для запуска можно использовать новые возможности Java для уменьшения размера заголовков объектов и использование более продвинутого Garbage Collector - ZGC.

SET JAVA_HOME=C:\PROGRAM FILES\JAVA\jdk-25
SET JAVA_EXE="%JAVA_HOME%\bin\java.exe"
chcp 65001
%JAVA_EXE% -XX:+UseCompactObjectHeaders -XX:+UseZGC -Xmx2024m -DLaF=dark -Dfile.encoding=UTF8 -jar dimension-ui-25.10.2-app.jar

pause

Все настроено и готово для сравнения, приступим.

Метрики

Grafana

Посмотрим как организован просмотр метрик в Grafana - Drilldown - Metrics.

Grafana - интерфейс просмотра Метрик
Grafana - интерфейс просмотра Метрик

В этом интерфейсе доступны все метрики подключенные от источников данных. В нашем случае это данные истории активных сессий через custom-postgres-exporter и все метрики хранилища данных Prometheus. Очень удобная навигация и просмотр данных, скролл по данным метрикам работает без проблем, можно переключаться между Grid/Rows представлением. Если навести мышь на элемент в одном графике - отображается курсор и по всем остальным - удобно когда масштаб выводимых значений у графиков разный (единицы, десятки, сотни по оси Y).

Есть возможность перейти в настройки каждой метрики и выбрать отображение данных по типу функции: Sum (default), Average, Standard deviation, Percentiles и Minimum and maximum. Сразу видно вид графика при применении функции - это наглядно и удобно. Есть возможность выбрать график, например pg_stat_database_active_time_seconds_total и посмотреть посмотреть информацию по datname, dateid instance и job на вкладке Breakdown (разбивка) или связанные Related metrics - то есть посмотреть на другие метрики, выбрать по тэгу и сравнить с текущим выбранным графиком - тоже удобно.

Для просмотра детализации по выбранному временному диапазону - просто выбираем его на графике и фильтр по диапазону автоматически применится по всем графикам.

Grafana - интерфейс просмотра Метрик
Grafana - интерфейс просмотра Метрик
Grafana - интерфейс просмотра Метрик

Dimension-UI

Теперь смотрим как организован просмотр метрик в Dimension-UI в интерфейсе Workspace.

Dimension-UI - интерфейс Workspace -> Preview
Dimension-UI - интерфейс Workspace -> Preview

В приложении Dimension-UI есть возможность просмотреть все метрики в едином интерфейсе в Workspace только по выбранному запросу получения данных. Доступно только Rows представление, Grid пока не реализован. Есть фильтрация по имени метрики, по скроллу можно легко добраться до нужного графика. Если требуется смотреть разные метрики в одном представлении - нужно перейти в интерфейс Dashboard, там можно взять метрики из любых профилей, заданий и запросов и смотреть их в одном интерфейсе. Есть удобный скрол и просмотр детализации - об этом в следующем разделе.

Есть возможность в настройках каждой метрики выбрать отображение данных по типу функции: Count, Sum, Average - нет Standard deviation, Percentiles и Minimum and maximum. В планах реализовать Percentiles, так как это очень полезная функция для детекции аномалий (выбросов) в данных. Count в Dimension-UI - это расчет моды по измерению за определенный период времени и данное отображение выбирается автоматически по типу строковому типу данных. Для числовых типов данных - по умолчанию устанавливается функция Average, есть возможность быстрого переключения между функциями в интерфейсе - это удобно.

Для просмотра детализации по выбранному временному диапазону - просто выбираем его на графике и в нижней части графика отобразится детализация по выбранным измерениям в формате Gantt графика. При необходимости можно посмотреть сводный отчет Pivot, данные в табличном виде Raw или детализацию по выбранному диапазону в Data, просмотр аномалий Anomaly и прогнозирование Forecast.

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

Dimension-UI - интерфейс Workspace -> Preview
Dimension-UI - интерфейс Workspace -> Preview
Dimension-UI - интерфейс Workspace -> Preview

История активных сессий

Grafana

Чтобы реализовать просмотр истории активных сессий, необходимо разработать dashboard и загрузить его определение с помощью JSON файла - об этом было в разделе Настройка окружения. Переходим в Dashboards -> PostgreSQL Active Sessions History и смотрим как отображаются данные по истории активных сессий. Предварительно лучше запустить эмуляцию нагрузки в PostgreSQL через pgbench.

Grafana - интерфейс просмотра истории активных сессий PostgreSQL
Grafana - интерфейс просмотра истории активных сессий PostgreSQL

На dashboard-е наблюдаем график истории активных сессий в верхней части и детализация по выбранному диапазону в нижней. Можно выбрать диапазон для любого периода времени и выполнить drill-down с просмотром детализации.

Можно применить фильтр по группе ожиданий, в левой верхней части dashboard-а. Фильтр сделан удобно - значения в виде тэгов. Или можно выбрать группу ожиданий в правой части, тогда данные на графике покажут только определенную группу ожиданий.

В настройках графика dashboard-а можно установить размер и тип графика, выбрать подписи осей X,Y, сглаживание линий и другие параметры, которых немало. Можно к текущему графику на dashboard-е добавить еще несколько.

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

Grafana - интерфейс просмотра доп. графиков истории активных сессий PostgreSQL
Grafana - интерфейс просмотра доп. графиков истории активных сессий PostgreSQL
Grafana - интерфейс просмотра истории активных сессий PostgreSQL
Grafana - интерфейс просмотра истории активных сессий PostgreSQL
Grafana - интерфейс просмотра истории активных сессий PostgreSQL

Dimension-UI

В Dimension-UI для просмотра истории активных сессий можно использовать один из вариантов - Workspace, предназначенный больше для просмотра подробной информации по метрике в режиме реального времени и истории или Dashboard - который больше предназначен для удобного просмотра данных по всем измерениям в одном интерфейсе в Realtime режиме - детализация доступна по клику на кнопку Details в настройках графика.

Такой момент, в приложении Dimension-UI есть разделение между интерфейсам для просмотра Realtime и History данных метрики/измерения. Сделано это для удобства хранения состояния по выбранному диапазону, чтобы спокойно можно было смотреть отдельно текущий статус изменений Realtime и делать drill-down по различным измерениям в History.

Dimension-UI - интерфейс Dashboard - История активных сессий PostgreSQL
Dimension-UI - интерфейс Dashboard - История активных сессий PostgreSQL

В интерфейсе Dashboard метрики представлены списком, все необходимое под рукой - достаточно выбрать то или иное измерение по запросу данных.

При необходимости добавить метрики/измерения из другого запроса (из любого профиля или задания) - просто выбираем в правой части с помощью checkbox значение - график будет добавлен на основную панель с dashboard-ми.

Можно быстро получить доступ к нужному представлению данных на графике через выбор функции: Count, Sum или Average. Если нужна детализация и более подробный анализ данных - запускаем расширенную версию через кнопку Details.

На практике часто приходится видеть всплески по определенным событиям, в Dimension-UI отследить их очень просто. Например, возьмем метрику Duration запустим детализацию и увидим, что основные ожидания идут по группам ожиданий Timeout и Lock - в PostgreSQL это операции по очистке строк в таблице, помеченных для удаления - в запросах видим какие команды выполнялись дольше всего (по Duration).

Dimension-UI - интерфейс Dashboard - детализация по Duration - История активных сессий PostgreSQL
Dimension-UI - интерфейс Dashboard - детализация по Duration - История активных сессий PostgreSQL
Dimension-UI - интерфейс Dashboard - История активных сессий PostgreSQL
Dimension-UI - интерфейс Dashboard - История активных сессий PostgreSQL
Dimension-UI - интерфейс Dashboard - История активных сессий PostgreSQL

Итоги

Grafana и Dimension-UI успешно справились с задачей мониторинга истории активных сессий в базе данных PostgreSQL. Все достаточно просто и интуитивно понятно в части визуализации данных, настройка не должна вызвать каких-либо проблем.

Что же выбрать? Решать вам, я постарался предоставить всю доступную на данный момент информацию (не исчерпывающую) по инструментам для принятия решения. Смотрите, пробуйте - какой способ работы с данными удобен, через какие интерфейсы задача решается быстрее/удобнее, с меньшей когнитивной нагрузкой и проч.. Есть скриншоты и скринкасты, если нет возможности запускать приложение.

Далее, некоторые мои субъективные соображения (спорные утверждения) по результатам сравнения.

  • Web/Desktop: У меня есть ощущение, что реализовать приемлемый уровень интерактивности с использованием Web для среднего уровня объема данных, скажем так непросто - если вообще возможно на текущем уровне развития технологий общего назначения. А может и не надо этого делать, может для локальных данных проще использовать нативные приложения? Опять же безопасность - для Desktop решения проще простого организовать VDI, огородить все и вся и спокойно давать доступы на просмотр. Или как вариант - использование Desktop решения в качестве резервной системы мониторинга, без инвестиций - так как в Dimension-UI настоящий low code/no code (вот).

  • Потребление ресурсов: Простой пример из текущей практики тестирования Grafana - я переключаюсь на страницу Home -> Drilldown -> Metrics и потребление ОЗУ в браузере Firefox с 400 Мб сразу скачет в 900 Мб. 4 вкладки и почти гигабайт ОЗУ. В Dimension-UI в прошлой статье при 300+ одновременно запущенных графиков ~ 400 Мб стабильно.

  • Stateless/Stateful drilldown: Когда в Grafana выбираешь диапазон на графике, мы делаем drilldown в детализацию из предыдущего состояния в новый диапазон - назовем это stateless drilldown. В Dimension-UI не так, выделенный диапазон и детализация у тебя перед глазами, плюс раздельно Realtime и History by design - stateful drilldown. По моему мнению, stateful drilldown дает меньше когнитивной нагрузки, в Grafana (да и в других системах с аналогичным подходом) меня это вышибает из потока, требует больше действий, чтобы вернуться в обратное состояние, невозможно попереключаться между режимами. Как вариант - плодить вкладки в браузере.. Тоже решение, не спорю.

  • Универсальность / Специализация: Grafana - система общего назначения для мониторинга метрик, с задачей детального анализа данных справляется не очень хорошо, это видно по графикам истории активных сессий. Честно говоря, очень красиво/интересно - но ничего непонятно. В Dimension-UI в этом смысле все видно хорошо - где какие всплески, кто за них ответственен и проч. Может есть какие-то платные расширения или другие способы организации dashboard-ов подобного типа в Grafana? Напишите в комментариях, могу чего-то не знать.

  • Зрелость экосистемы: Grafana по этому показателю в лидерах — отраслевой стандарт с многолетней историей развития. Тысячи готовых дашбордов и плагинов для любых источников данных. Dimension-UI — это нишевое решение. Фокус на решении конкретной задачи (детальный анализ временных рядов) максимально эффективным и удобным способом.

Ссылки и дополнительные материалы

  • Grafana: https://grafana.com/
    Программное обеспечение для визуализации и анализа метрик. Позволяет строить дашборды, графики и алерты на данные из различных источников, включая Prometheus и PostgreSQL.

  • Prometheus: https://prometheus.io/
    База данных временных рядов (TSDB), предназначенная для хранения метрик мониторинга.

  • PostgreSQL: https://www.postgresql.org/
    Реляционная система управления базами данных (СУБД).

  • Dimension UI: https://github.com/akardapolov/dimension-ui/ — десктопное приложение, предназначенное для сбора, хранения, визуализации и анализа данных временных рядов.

  • Статья на Хабре: «Визуализация Active Session History в PostgreSQL — делаем просто и красиво». https://habr.com/ru/companies/uzum/articles/865622/

  • Статья на Хабре: «Мониторинг с Grafana. Best practices». https://habr.com/ru/companies/karuna/articles/771134/

Вроде все, спасибо за внимание!

Комментарии (6)


  1. gecube
    16.10.2025 15:48

    Я вообще не понимаю, как можно сравнивать десктопное приложение и серверное ? Вот, скажем, нет доступа к серверу pg напрямую. Закрыто сетевой политикой. Или есть, но непривилегированный пользователь ?

    Графана в этом кейсе на раз два выиграет.

    А исторические данные ? У меня были кейсы, когда нужны метрики за 3 месяца назад. Как тут Dimension UI поможет ? Конечно, утилита выглядит красивой и интересной. Но вот суть ее уже ставит серьёзные вопросы на ее применимость. Вот бы было здорово ее как то на сервере запустить, закрыть паролем и так смотреть?


    1. akardapolov Автор
      16.10.2025 15:48

      Я вообще не понимаю, как можно сравнивать десктопное приложение и серверное?

      Можно сравнить. Только не абстрактно, а на конкретной задаче и посмотреть как она решается с помощью инструментов.

      Вот, скажем, нет доступа к серверу pg напрямую. Закрыто сетевой политикой. Или есть, но непривилегированный пользователь?

      Если нет прямого доступа - ставим в DMZ рядом с PG виртуальную машину и ходим на нее по защищенному каналу. Для непривилегированного пользователя даем права на просмотр данных мониторинга, и ходим также через виртуалку VDI. Снимаем целый пласт проблем с безопасностью, если сравнивать с Web.

      А исторические данные ? У меня были кейсы, когда нужны метрики за 3 месяца назад. Как тут Dimension UI поможет ?

      Если локально сбор настроен с использованием Dimension-UI - смотрим историю (вкладка History). Если локально нет данных, но они есть в БД - идем на вкладку Ad-Hoc и смотрим данные напрямую, без написания SQL-запросов (No-code). Тут можно посмотреть, раздел AdHoc запросы.

      Вот бы было здорово ее как то на сервере запустить, закрыть паролем и так смотреть?

      Да, именно так. VDI в этом случае решает. Лично неоднократно наблюдал, как ASH-Viewer разворачивали на виртуальной машине и параллельно с штатным мониторингом держали ее в резерве для просмотра истории, при разборе инцидентов etc. Тоже самое можно делать и с Dimension-UI.

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

      Работа с данными должна быть удобной. Пока на Desktop, но если данный подход покажет свою эффективность - не проблема развернуть Web-версию, с текущим то развитием технологий LLM. Или конкуренты подтянутся и реализуют похожую функциональность - тоже хорошо.


      1. gecube
        16.10.2025 15:48

        Да, именно так. VDI в этом случае решает. Лично неоднократно наблюдал, как ASH-Viewer разворачивали на виртуальной машине и параллельно с штатным мониторингом держали ее в резерве для просмотра истории, при разборе инцидентов etc. Тоже самое можно делать и с Dimension-UI.

        это звучит диковато, потому что мониторинг у вас и так, и так будет хоть какой-то и интегрировать туда сбор данных с постгреса не является большой проблемой. Лично в тех организациях, где я работал, выделение отдельной vdi с графическим режимом - куда большая проблема. Не говоря уже о том, что кто будет держать ее 24/7, чтобы метрики были доступны - это попросту дорого. Дороже, чем графана и прометеус.

        Если локально сбор настроен с использованием Dimension-UI - смотрим историю (вкладка History). Если локально нет данных, но они есть в БД - идем на вкладку Ad-Hoc и смотрим данные напрямую, без написания SQL-запросов (No-code). Тутможно посмотреть, раздел AdHoc запросы.

        Можно подробнее ? Это может быть существенным моментом.


        1. akardapolov Автор
          16.10.2025 15:48

          это звучит диковато

          Если это делали - значит было удобно. Значит была/есть потребность в таком типе работы с данными мониторинга.

          выделение отдельной vdi с графическим режимом - куда большая проблема

          Орг. моменты, решаются при необходимости.

          Можно подробнее ? Это может быть существенным моментом.

          Идем по подключению в БД, выбираем таблицу или представление. Далее выставляем метку времени, выбираем метрики/измерения - и смотрим график за любой период, с фильтрами. Без написания SQL.

          Ad-Hoc интерфейс
          Ad-Hoc интерфейс


          1. gecube
            16.10.2025 15:48

            Требования к мониторингу какие ? Что на инстансе постгреса надо крутить? Исторические данные в нем же самом хранятся ?


            1. akardapolov Автор
              16.10.2025 15:48

              Требования к мониторингу какие ?

              Зависит от объемов, если что-то критичное - лучше данные мониторинга складировать в отдельную БД. Можно и на хосте который мониторим, если нагрузка небольшая. Сами данные мониторинга агентом загружаем в таблицу истории активных сессий - и по ней смотрим статистику. Можно грузить любые данные, не только историю активных сессий, нужные метрики собирать запросом и смотреть состояние системы.

              В Dimension-UI данные с удаленных систем можно собирать на клиентской станции, где установлено приложение. Приложение в этом случае работает как агент для сбора данных или же подтягивать изменения из уже сохраненных таблиц на удаленной системе — приложение автоматически отслеживает метку времени и подгружает данные в пакетном режиме в локальную БД (метка времени в данных мониторинга устанавливается уже извне, через внешнего агента, которые пишет данные в таблицы - как в Active session history Oracle). В первом случае в настройках по запросу указываем BY_CLIENT_JDBC, а для второго варианта — BY_SERVER_JDBC. Подробности по настройке приложения есть в документации на Github.