Комментарии 14
А что означает суффикс otel? В статье про OpenTelemetry ни слова.
И почему этого нет в contrib?
Добрый день.
Спасибо за новый интересный инструмент для мониторинга БД. Здорово, что появляются новые решения.
Часто нужно пушить метрики, а не скрейпить. Если пользоваться prometheus exporter с частично схожим функционалом, то для push метрик нужно было дополнительные упражнения делать.
На данный момент мне кажется вам не хватает каких-то готовых дашбордов по этим метрикам, для графаны например. Метрик много, и смотреть в каждую метрику кожаным мешкам уже тяжело.
Если взять тот же prometheus exporter, к нему уже есть готовые дашборды, хотя бы на сайте графаны, и можно посмотреть в целом на состояние БД, более в человеко..читаемом виде, не заглядывая в каждую метрику отдельно.
Percona Monitoring and Management (PMM) использует под капотом postgresql exporter для метрик, и имеет в комплекте помимо дашбордов ещё и аналитику (алертинг по метрикам), можно просто включить и смотреть по мере необходимости в уже готовые дашборды. Ну и дополнительно статистику по запросам (pg_state_statemets) они хранят в clickhouse
Okmeter предоставляет помимо метрик в чистом виде и дашборды, и алертинг, и рекомендации по запросам (например, добавить индекс), но это, как и РММ, целый комбайн, только он не только базы мониторить может. Но вот агент у него очень лаконичный - один бинарь и даже без конфигурации.
Если выбирать между prometheus exporter и pgpro-otel прямо сейчас, я бы наверное пока использовал postgresql prometheus exporter. Просто потому что я знаю что искать в тех сотнях метрик, которые он экспортирует. У вас же метрики по большей части те же самые, но с другим неймингом. И нет инструментов для их анализа, их нужно делать самим.
Привет, вы все верно говорите, анализировать метрики, вчитываться в их HELP описания это нудная рутина, я сам много раз играл в эту игру. По дашбордам работы ведутся и в след. релизе дашборды будут идти в комплекте.
А планируется ли подружить это с pg_profile для доступа к данным по отдельным запросам?
Метрики pgbouncer, patroni будут?
А планируется ли подружить это с pg_profile для доступа к данным по отдельным запросам?
Интеграция с pg_profile пока не рассматривалась. А для сбора метрик по отдельным запросам можно включить соотв. плагины (начинаются с префикса statements) и на мой скромный взгляд, за счет мощи promql/metricsql/grafana получить гораздо большие возможности.
Метрики pgbouncer, patroni будут?
pgbouncer определенно да, patroni скорей всего нет, т.к. целевой HA менеджер это BiHA, а patroni с пониженным приоритетом.
Алексей, спасибо за статью. Возник вопрос:
В выходных данных в формате прометея коллектор отправляет временную метку (параметр send_timestamps: true в секции exporters -> prometheus)
Так вот у некоторых метрик таймстамп сильно отличается друг от друга, буквально единицы минут (см скрин ниже). Почему так происходит? Это какой-то механизм кэширования данных или что-то иное? Спасибо.
Да это кэширование на уровне экспортера, регулируется параметром metric_expiration экспортера. Экспортер не знает когда к нему придет скрейпер, поэтому удерживает метрики некоторые время которые могли пропасть (в плане постгреса это характерно для GAUGE-подобных метрик activity и locks).
Кажеться, что по дефолту там 5 минут и если мы будем кэшировать метрики которые должны отражать реалтайм данные (к примеру число коннектов в разных состояниях), то можем выстрелить себе же в ногу.
Просто в контексте push модели для otel коллектора и pull для эндпойнта прометея непонятно куда и какое число улетит и где будет актуальное на момент времени.
то можем выстрелить себе же в ногу.
а продолжите мысль
Просто в контексте push модели для otel коллектора и pull для эндпойнта прометея непонятно куда и какое число улетит и где будет актуальное на момент времени.
prometheus экспортер не умеет в push модель, только pull. а в случае прометея все зависит от того как настроите сам прометей
Знакомство с pgpro-otel-collector