Метрики Gateway

Gateway — это пользовательская PostgreSQL‑точка входа SPG99, поэтому именно его метрики лучше всего отвечают на вопросы “почему приложение не подключается”, “как ведёт себя pool” и “не мешает ли клиентский трафик autoscale handoff”.

Базовые сигналы живости

• up на metrics‑порту — доступен ли сам gateway;
• /health — быстрый probe для liveness/health.

TLS и backend‑подключение

gw_backend_tls_ok_total

Считает успешные backend TLS‑handshake между Gateway и Compute.

gw_backend_tls_handshake_errors_total

Показывает ошибки backend TLS‑handshake. Полезно при проблемах с CA chain, SNI и пересоздании backend‑сертификатов.

Lease и lifecycle базы

spg99_lease_active

Показывает, активен ли lease для конкретной базы.

spg99_lease_acquire_total

Считает попытки acquire lease, включая ошибки.

Практический смысл: по этим метрикам хорошо видно, будит ли Gateway sleeping‑database, не застревает ли lease path и не удерживается ли база дольше нужного из‑за клиентской активности.

Pooling и pressure на backend

spg99_pool_total_conns

Сколько backend‑соединений открыто в pool.

spg99_pool_idle_conns

Сколько backend‑соединений лежит idle и готово к reuse.

spg99_pool_checkout_wait_seconds

Сколько времени клиенты ждут выдачи backend‑соединения.

spg99_pool_checkout_timeouts_total

Сколько раз checkout упёрся в timeout/exhaustion pool.

spg99_pool_backend_connect_total

Сколько было попыток открыть backend‑соединение, с разбивкой по результату.

spg99_pool_resets_total

Сколько backend‑соединений reset‑илось перед reuse.

Что особенно важно для нового autoscaler

spg99_session_pinned_total

Показывает, как часто сессии переходят в pinned state и по какой причине.

Это особенно полезно, когда:

• приложение неожиданно начало использовать SET, temp tables, cursors, LISTEN или named prepared statements;
• transaction pooling перестал давать ожидаемую экономию;
• autoscale handoff не может дойти до безопасного drain.

Freeze и cutover

Когда freeze_new_checkouts=true, Gateway должен перестать выдавать новые checkout'ы на старый writer. В этот момент особенно полезно смотреть:

• checkout waits;
• checkout timeouts;
• pinned sessions;
• общую длительность lease и число активных соединений.

Как интерпретировать метрики на практике

Сценарий 1: подключения медленные только после простоя

Смотрите spg99_lease_acquire_total, spg99_lease_active, spg99_pool_backend_connect_total и длительности checkout. Если старт медленный только на sleeping‑database, это нормальный cold start path.

Сценарий 2: handoff завис на freeze/drain

Смотрите spg99_session_pinned_total, checkout wait и общее число активных/idle клиентских соединений. Часто проблема не в платформе, а в workload, который держит слишком много session‑state.

Сценарий 3: приложение упирается в pool

Смотрите spg99_pool_checkout_timeouts_total, spg99_pool_total_conns, spg99_pool_idle_conns. Если timeout‑ы растут при нулевом idle‑пуле, нужно либо расширять профиль, либо уменьшать fan‑out клиентов, либо разбираться, почему workload pin‑ит сессии.

Сценарий 4: маршрут до backend нестабилен

Смотрите gw_backend_tls_handshake_errors_total и spg99_pool_backend_connect_total{result=...}. Это помогает быстро отделить route/TLS‑проблему от ошибок клиентского логина.

Практический вывод

Для Gateway метрики — это главный способ понять:

• работает ли autostart;
• даёт ли pooling реальную экономию;
• не превратился ли workload из stateless в session‑heavy;
• не мешает ли pinned traffic безопасному autoscale handoff.