Практикум: метрики пула соединений SQLAlchemy¶
Сервис заказов может ждать соединение из SQLAlchemy, выполнять медленный SQL, держать соединение во время расчёта доставки или стоять в очереди PgBouncer. Скрипт разделяет эти случаи с помощью настоящих соединений с БД и значений метрик Prometheus.
Нужны Docker и uv. Выполните команду из каталога практикума:
| Сценарий | Проверка |
|---|---|
| Единственное соединение локального пула занято | Второе получение завершается по таймауту через 200 мс; счётчик таймаутов увеличивается на единицу; после освобождения соединения следующий запрос проходит |
SQL выполняет pg_sleep(0.2) |
Сумма наблюдений гистограммы времени удержания увеличивается примерно на 200 мс или больше |
| Доставку ждут внутри транзакции | Во время внешнего ожидания остаётся одно выданное соединение |
| Доставку ждут после завершения транзакции | Выданных соединений нет, ответ не меняется |
| У SQLAlchemy два клиентских соединения, у PgBouncer одно серверное | Соединение из SQLAlchemy уже получено, SHOW POOLS показывает cl_waiting=1, а счётчик локальных таймаутов остаётся нулевым |
События удерживают транзакции и тестовую реализацию доставки в ожидании, пока скрипт не проверит нужное состояние. PostgreSQL 17 и PgBouncer 1.25.2 работают во временных контейнерах. Это проверка поведения, а не замер максимальной производительности.
В последнем сценарии оба клиентских соединения уже открыты, pre-ping и автоматическая установка схемы отключены. Иначе дополнительный SQL может перенести ожидание серверного соединения на этап получения клиентского соединения или начала транзакции.
Скрипт импортирует настройку окружения и функции из статьи из соседнего практикума PgBouncer. Его requirements.txt подключает закреплённые зависимости того практикума. Если копируете пример, сохраните оба каталога. Каждый менеджер использует отдельный префикс метрик, чтобы избежать повторной регистрации в Prometheus.