Транспортные метрики
Транспортные метрики связаны с тем, как сервисы обмениваются данными — через HTTP-запросы или соединения с базой данных PostgreSQL. Они показывают скорость отклика, количество активных соединений, частоту и длительность SQL-запросов, ошибки в работе БД или API. Такие метрики помогают находить причины замедлений в ответах пользователям, устранять блокировки или утечки соединений, а также выявлять «тяжелые» запросы, которые нагружают систему и требуют оптимизации.
Введение
Этот дашборд предназначен для мониторинга HTTP-запросов, соединений с базой данных PostgreSQL и анализа SQL-запросов. Используется Prometheus в качестве источника данных, а отображение производится через панели Grafana.
Общее описание дашборда
Дашборд состоит из нескольких секций:
- HTTP — Клиенты и пользователи
- Postgres — Транзакции, соединения
- Postgres — Анализ запросов
- Postgres — Топ запросов и детализация
Каждый раздел содержит метрики в формате Time Series или Stat с метками, легендами и пороговыми значениями. Все панели обновляются каждые 10 секунд.
Раздел: HTTP — Клиенты и пользователи
| Название панели | Описание | Применение |
|---|---|---|
Active Connections Over Time | Количество активных соединений public и internal. | Эта панель помогает вовремя замечать всплески нагрузки. Если резко растёт число public-соединений, это может говорить о росте пользовательской активности или возможной DDoS-атаке. В таком случае стоит проверить логи Nginx, чтобы исключить атаки или неожиданно высокий трафик. Рост internal-соединений часто указывает на утечки соединений, длинные висящие запросы или блокировки в коде или базе данных. |
Users HTTP Request Duration | Время отклика внутренних HTTP-запросов. | Если время ответа превышает 1 секунду, стоит выяснить, какой именно запрос или участок кода создаёт задержки. При высоких значениях нужно анализировать трассировки (tracing), профилировать медленные обработчики (handlers), проверять запросы к базе данных, состояние очередей и работу сторонних сервисов. |
Users Request Rate by Endpoint | Частота внутренних HTTP-запросов к endpoint-ам. | Эта панель помогает определить самые нагруженные маршруты и понять, какие части системы требуют оптимизации или кэширования. Если отдельные endpoint начинают перегружаться, стоит подумать о кэшировании, оптимизации SQL-запросов, сокращении передаваемых данных или введении ограничений на частоту запросов (throttling или rate limiting). |
Clients HTTP Request Duration | Аналогично Users HTTP Request Duration, но для внешних пользователей. | Если долго — пользователи могут ждать или получать ошибки. Сравниваем с Users-панелью, чтобы понять, тормозит ли сервер или сеть. При высоких задержках — проверять балансировщики, состояние сетевых каналов, CDN, и backend-ответы. |
Clients Request Rate by Endpoint | Частота запросов внешних пользователей по endpoint-ам. | Это позволяет вовремя заметить аномальный трафик, например, скриптовые атаки или резкие всплески пользовательской активности. В случае подозрений стоит анализировать IP-адреса, User-Agent, блокировать подозрительные запросы на уровне фаервола. Для популярных endpoint стоит рассмотреть кэширование или введение ограничений по частоте запросов. |
Раздел: Postgres — Транзакции, соединения
| Название панели | Описание | Применение |
|---|---|---|
Макс. возраст подключения | Максимальная длительность открытого соединения к PostgreSQL. | Позволяет понять какое соединение висит дольше всего и занимает ресурсы. Если время большое — проверить активные соединения, завершить висящие, проверить код на утечки соединений или долгие транзакции. |
Всего подключений, неактивные, ожидающие | Количество соединений в PostgreSQL в разных состояниях. | Если много waiting — проверить блокировки или длинные запросы. Если много idle — проверить, закрываются ли соединения в коде или в пуле. Может потребоваться увеличение лимитов соединений или настройка пула соединений. |
Транзакции | Количество активных и висящих транзакций. | Позволяет отследить, есть ли транзакции, которые висят без завершения. Долгие или зависшие транзакции могут блокировать другие запросы (например, удерживая locks на таблицах или строках). При росте зависших транзакций нужно анализировать активные сессии, искать запросы с долгим временем выполнения, и при необходимости завершить блокирующую транзакцию. |
Current Active Connections | Текущее число активных соединений (public + internal). | Используется для оценки текущей нагрузки. Резкий рост активных соединений может указывать на утечки соединений в коде (например, забыли закрывать соединение в пуле) или на слишком низкие лимиты в пуле. |
Current PostgreSQL Transactions | Если увеличивается число зависших транзакций → это сигнал к поиску блокировок, медленных или «зависших» запросов, или ошибок в коде, когда транзакции не завершаются | |
Connection States | Сводка по соединениям: Active tx, Hanging tx, Idle conn, Waiting conn. | Даёт общую картину работы БД. Рост Hanging tx или Waiting conn → признак блокировок или зависших запросов. Нужно анализировать pg_stat_activity и pg_locks, чтобы найти причину блокировки. Рост Idle conn → может говорить об утечке соединений или слишком долгом удержании соединений в пуле. При Idle нужно проверять таймауты в пуле и корректное закрытие соединений в коде. |
Раздел: Postgres — Анализ запросов
| Название панели | Описание | Применение |
|---|---|---|
Обработанные строки | Количество обработанных строк в секунду по SQL-запросам. | Используется для оценки активности и эффективности запросов. Если число строк резко падает при том же количестве запросов — возможны блокировки или изменения в планах выполнения (например, перестали использоваться индексы). Что делать: проверить активные запросы через pg_stat_activity, наличие блокировок через pg_locks, выполнить EXPLAIN/EXPLAIN ANALYZE для ключевых запросов. |
Общее время выполнения запросов | Топ-5 SQL-запросов с наибольшим временем выполнения. | Помогает определить, какие запросы чаще всего тормозят систему. Если один запрос потребляет много времени, его нужно оптимизировать (добавить индекс, переписать, разбить на более мелкие). |
Ошибки запросов | Количество SQL-ошибок по типам. | Показывает, есть ли проблемы в коде приложения или сбои при работе с базой. Если количество ошибок растёт, это признак багов или неправильной конфигурации. Что делать: анализировать логи PostgreSQL (log_line_prefix, log_statement), выявлять и исправлять некорректные запросы. |
Количество вызовов запросов | Число вызовов SQL-запросов за период. | Помогает выявить слишком частые запросы, которые создают нагрузку. Что делать при росте: подумать о кэшировании данных, батчинге запросов или изменении архитектуры взаимодействия с БД. |
Среднее время выполнения | Среднее время выполнения SQL-запросов. | Нужна, чтобы отследить изменения производительности. Если среднее время растёт, это может быть сигналом о деградации индексов или перегрузке. Что делать: анализировать планы (EXPLAIN), проверять, не выросло ли количество строк в таблицах. |
Раздел: Postgres — Топ запросов и детализация
| Название панели | Описание | Применение |
|---|---|---|
Top Queries by Call Rate | Таблица с запросами, отсортированными по количеству вызовов, среднему времени и строкам/сек. | Используется для поиска самых «нагруженных» запросов. Если запрос вызывается слишком часто и потребляет ресурсы, его оптимизируют или переносят в кэш. Что делать: проверять логику вызова в приложении, добавлять индексы, пересматривать архитектуру. |
Детализация по запросу | Фильтрация по $query для анализа вызовов и строк конкретного запроса. | Позволяет изучить проблемный запрос в деталях. Если запрос регулярно занимает много времени, его надо разложить на составляющие и искать оптимизацию. Что делать: собрать EXPLAIN ANALYZE, смотреть статистику использования индексов, оценивать план запросов. |
Как искать уязвимые места
- Просадки по
p95времени ответа — указывают на "узкие горлышки". - Висящие транзакции (
pg_hanging_transactions) — потенциальные deadlocks. - Высокий процент неактивных/ожидающих соединений — возможны утечки или неосвобожденные ресурсы.
- Частые ошибки SQL-запросов — сигнализируют о баге или некорректной логике.
- Топ-5 долгих запросов — кандидаты на оптимизацию индексов или плана выполнения.
Как сравнивать дашборды
- Временной интервал: Убедитесь, что сравнение идет по одинаковому периоду.
- Конфигурация панелей: Сравните Prometheus выражения (expr), используемые метрики и уровни порогов.
- Показатели "до и после": Применяйте при оптимизациях, чтобы видеть эффект.