Таймауты запросов не всегда означают проблему в базе данных. Часто деградация скрыта в пути между приложением и БД.
Проблема проявляется в момент, когда метрики базы выглядят стабильными, но клиенты получают таймауты. На уровне наблюдения это выглядит как противоречие: latency растёт, а database time остаётся прежним. Причина в том, что пользовательский опыт формируется не временем выполнения запроса в БД, а полной round-trip задержкой. В неё входят connection pools, load balancers, прокси и сеть. Большинство инструментов мониторинга базы видят только внутреннее выполнение запроса, поэтому деградация вне БД остаётся невидимой.
Подход сводится к разложению latency на две части: database time и всё остальное. Это отношение удобно рассматривать как parent/child модель. Родитель — полный round trip (от отправки запроса до получения ответа). Внутри время выполнения в БД и внешний оверхед. Ключевой вопрос: какая часть доминирует. Если database time растёт, есть смысл оптимизировать запросы или масштабировать БД. Если растёт внешний компонент, то проблема в инфраструктуре, и оптимизация SQL не даст эффекта. Это простой, но критичный с точки зрения диагностики срез.
Реализация строится на корреляции двух источников данных. APM фиксирует полный round trip, так как работает на стороне приложения и измеряет весь путь запроса. Database Monitoring, напротив, берёт метрики непосредственно из БД (например, total_exec_time в Postgres), где учитывается только время выполнения запроса без передачи данных клиенту. Разница в этих двух измерениях и есть искомый внешний оверхед. На практике это представляют как коэффициент round trip / database time. Рост этого значения указывает на деградацию вне БД. В рассмотренном сценарии причиной оказался PgBouncer: при росте нагрузки его single-threaded event loop упёрся в CPU, что увеличило задержку на уровне пула соединений.
Результат такого подхода — это сокращение времени диагностики и снижение числа ложных гипотез. Вместо перебора оптимизаций внутри базы можно сразу локализовать слой проблемы. В приведённом кейсе это позволило отказаться от тюнинга запросов и масштабировать PgBouncer через добавление инстанса и балансировку. Конкретные метрики улучшения не указаны, но сам сдвиг фокуса с БД на инфраструктуру устранил источник таймаутов.