Comments 4
Это же просто Prometheus для баз данных! Здорово!
Если БД находится в загруженном состоянии ~ 1000сессий например, с постоянной высокой нагрузкой, насколько сильно такой мониторинг будет влиять на саму БД?
Все зависит от самой БД, от среднего размера сохраняемых данных. В Oracle например сбор статистик встроен в ядро, там это происходит очень быстро (прямое чтение данных из спец.структур в памяти, в 10.1 были SQL-запросы). Даже в самых тяжелых ситуациях запись истории активных сессий ведется. Для других БД - надо смотреть чтобы сбор данных мониторинга по времени происходил очень быстро. Если это запросы - то настраивать их на быстрое получение данных, если есть возможность другими способами снять трассировки - смотреть их.
В случае плоской таблицы, средний размер строки без больших запросов порядка 100-300 байт, в тяжелом случае (большие тексты запросов) порядка 1 Кб и выше. Время между замерами - 1 секунда.
Для 1000 сессий это примерно треть мегабайта данных для 300 байт средний размер строки. Их не проблема сохранить локально, и передать по сети и сохранить где-то еще.
Для 1000 сессий 1Кб размер строки - уже возникают сложности в части передачи их по сети - 1 Мб локально сохранить не проблема.
Поэтому в этом случае лучший вариант сохранять их на сервере (или где-то поблизости в спец. систему хранения для логов) и потом подтягивать на систему визуализации по мере необходимости. Аналогичная архитектура используется и в Oracle - история активных сессий сохраняется в БД локально.
В случае Dimension-UI - в первом случае можно забирать данные с удаленной системы или сохранять на сервере и подтягивать изменения через интервал 3 секунды и более (BY_CLIENT_JDBC или BY_SERVER_JDBC). Для больших объемов, только второй вариант BY_SERVER_JDBC.
Пределы по скорости записи для backend Dimension-UI (тут замеры производительности Dimension-DB) для локального индексирования дают значения порядка 10 Мб в секунду для сжатых данных (для несжатых умножаем на к=2-3).
Т.е. схема с BY_CLIENT_JDBC будет работать даже на таких объемах, но задержки на сетевом уровне, при отправке данных - схема не очень надежная. В общем лучше использовать BY_SERVER_JDBC для больших объемов данных.
В чём преимущество/отличие от связки exporter Prometheus grafana?
Хороший вопрос, потянет на отдельную статью. Вот она https://habr.com/ru/articles/956800/
Мониторинг истории активных сессий в базах данных