PgBouncer monitoring with Okmeter

Okmeter собирает данные обо всех соединениях и SQL запросах проходящих через PgBouncer. Это комплексное решение, с которым вы всегда будете в курсе текущей производительности работы вашего проекта. Детализация Okmeter позволит вам быстро выяснять причины любых проблем работы приложений со стеком PgBouncer/Postgresql.

Okmeter поможет вам всегда знать, что происходит с PgBouncer.

Окметр автоматически снимает детальную статистику про следующие операционные аспекты PgBouncer

Выполнение SQL запросов и транзакций
Серверные соединения
Клиентские соединения

Авто-обнаружение PgBouncer

Агент okmeter умеет автоматически обнаруживать и мониторить PgBouncer. По работающим на сервере процессам агент находит все запущенные экземпляры PgBouncer и сразу начинает снимать с каждого подробные метрики.

Так как в кластере и даже на одном сервере может работать несколько экземпляров PgBouncer, для идентификации экземпляра у всех метрики помимо метки source_hostname, по которой можно определить с какого сервера собраны показатели, есть ещё и метка instance, которая определяет конкретный инстанс PgBouncer на сервере.
Если PgBouncer запущен просто как сервис, вне контейнера, то в эту метку instance проставляется IP:PORT соответствующего listen сокета инстанса. А если PgBouncer запущен в docker, то метка instance будет содержать имя этого контейнера.

Мониторинг SQL запросов и транзакций

Основная задача PgBouncer — проксирование клиентских соединений для исполнения SQL запросов приложений в Postgres.
Проблемы с базой дынных правильно диагностировать по следующим симптомам:

время выполнения запросов существенно и неожиданно увеличилось или уменьшилось;
количество запросов / транзакций резко и неожиданно изменилось

Okmeter позволяет легко диагностировать подобные проблемы на основе подробных метрик по всем проходящим через PgBouncer в базу данных SQL запросам и транзакциям.

Мониторинговый агент okmeter собирает метрики PgBouncer периодически исполняя команду SHOW STATS;
По каждому инстансу PgBouncer у вас будет дашборд с графиками по следующим метрикам:

pgbouncer.total_requests {database: "D", instance: “Y”, source_hostname: “Z”}: Суммарное количество SQL запросов запроксированных в конкретную базу данных D.
По этой метрике удобно оценивать, есть ли аномалии в обычном профиле нагрузки:
pgbouncer.total_query_time {database: "D", instance: “Y”, source_hostname: “Z”}: Суммарное время активного выполнения PgBouncer'ом запросов в Postgres.
Эта метрика позволяет оценить среднее время выполнения запросов, как total_query_time / total_requests, что позволяет наглядно видеть изменения в том, на сколько быстро Postgres обрабатывает эти запросы:
pgbouncer.total_xact {database: "D", instance: “Y”, source_hostname: “Z”}: Суммарное количество транзакций запроксированных в конкретную базу данных D.
Можно построить график того, сколько в среднем на одну транзакцию приходится SQL запросов: поделив количество запросов, на количество транзакций — total_requests / total_xact. По такому графику легко видеть аномалии в профиле запросов в транзакциях:
pgbouncer.total_xact_time {database: "D", instance: “Y”, source_hostname: “Z”}: Суммарное время, которое PgBouncer провёл подключённым к базе D в Postgresql, или выполняя запросы, или ничего не делая и находясь в состоянии idle in transaction.
Эта метрика, совместно с total_query_time, позволяют оценить, какой процент времени соединения от PgBouncer'а находятся в Postgres'е в состоянии "ничегонеделанья". Это можно получить как 1 - total_query_time / total_xact_time:
pgbouncer.total_wait_time {database: "D", instance: “Y”, source_hostname: “Z”}: Суммарное время, которое клиенты ожидали подключения к базе D в Postgresql.
По этой метрике легко понять, что причина провала в производительности базы с точки зрения клиентов в том, что пула соединений от PgBouncer'а к Postgres базе перестало хватать:
pgbouncer.total_received {database: "D", instance: “Y”, source_hostname: “Z”}
pgbouncer.total_sent {database: "D", instance: “Y”, source_hostname: “Z”}: Суммарное количество байт, которое PgBouncer получил и отправил соответственно проксируя клиентские запросы.

Мониторинг серверных соединений PgBouncer

Агент okmeter собирает server connections метрики периодически исполняя команду SHOW POOLS;
По каждому инстансу PgBouncer у вас будет дашборд с графиками по следующим метрикам:

pgbouncer.server_connections.count {database: "D", user: "U", state: "S", instance: “Y”, source_hostname: “Z”}

Текущее количество открытых серверных соединений (т.е. от PgBouncer к Postgresql) в разных состояниях в соответствии с полями SHOW POOLS — sv_active, sv_idle, sv_used, sv_tested и sv_login.

active — серверное соединение выделено и сцеплено (linked) с клиентским соединением. И в этом соединении (в зависимости от pool_mode) или выполняется транзакция, или запрос, или возможно ничего не выполняется (если pool_mode = session).
idle — соединение в данный момент не используется никаким клиентом и готово к немедленному использованию.
login — соединение находится в процессе установки и авторизации.
used — не означает, что соединение используется, а только лишь, что соединение было в состоянии idle больше чем server_check_delay (по умолчанию 30 секунд), и требуется проверка его "живости" с помощью server_check_query.
tested — соединение находится в процессе вызова server_reset_query после использования предыдущим клиентом или вызова server_check_query для проверки "живости" соединения из-за того, что оно не использовалось больше чем server_check_delay.

Такие графики использования серверных соединений можно построить не только для одного инстанса PgBouncer, но и объединить на одном графике данные с нескольких PgBouncer в вашем production окружении. Или наоборот, несколько графиков, каждый — для конкретного пула соединений до конкретной базы данных:

Мониторинг клиентских соединений PgBouncer

Агент okmeter собирает client connections метрики периодически выполняя команду SHOW CLIENTS;
По каждому инстансу PgBouncer у вас будет дашборд с графиками по следующим метрикам:

pgbouncer.clients.count {database: "D", user: "U", client_address: "A", state: "S", instance: “Y”, source_hostname: “Z”}

Показывает количество всех текущих клиентских соединений с разных IP адресов во всех состояниях.
По этой метрике можно увидеть не только к каким базам, какие пользователи открыли много соединений, но и с каких IP адресов. Что позволяет диагностировать ненормативное поведение некоторых из них, как, например, тут:

Например, мы можем увидеть по графику среднего времени запросов, что ухудшилась производительность базы:

В данном случае было возросшее количество клиентских соединений. Окметр дает картину распределения таких соединений по состояниям:

active — клиентское соединение установлено.
active-link — клиентское соединение слинковано с серверным, т.е. клиенту выделено серверное соединение в данный момент, и клиент, возможно, выполняет запросы в рамках него.
waiting — клиентское соединение ожидает выделения / линковки с серверным соединением, т.к. клиент собирается или начать транзакцию или выполнить SQL запрос.

Такая ситуация может приводить к деградации производительности БД с точки зрения клиентов, и важно понять кто именно создал повышенную нагрузку в этот момент. Окметр позволяет выяснить на какую базу данных и от имени какого юзера были эти соединения. А еще, благодаря тому, что у этой метрики — pgbouncer.clients.count — есть метка (лейбл) client_address, легко понять с каких IP адресов были эти клиентские соединения, что дает возможность лучше и быстрее диагностировать причину проблемы:

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

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

А так как okmeter предупредит вас о такой ситуации благодаря встроенному автотриггеру, вы быстрее поймете где конкретно образовалась проблема и сможете скорее её исправить.

И это не всё!

Это лишь небольшая часть того, с чем okmeter поможет разбираться. Okmeter мониторинг не только покажет, как сейчас обрабатываются запросы в базу данных, но и оповестит, если с ними что-то идет не так.
Кроме того, okmeter знает и поможет вам понимать всё про все аспекты функционирования Postgres.

Вы будете всегда знать, что происходит с PgBouncer / Postgresql в каждый момент.