> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Query insights для Postgres
> Телеметрия по каждому оператору для Managed Postgres: все шаблоны запросов, которые выполняет ваша база данных, ранжированы по влиянию и снабжены диагностическими счётчиками, объясняющими, почему каждый из них работает медленно
export const Image = ({img, alt, size}) => {
return
;
};
export const galaxyOnClick = eventName => () => {
try {
if (typeof window !== "undefined" && window.galaxy && eventName) {
window.galaxy.track(eventName, {
interaction: "click"
});
}
} catch (e) {}
};
export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
if (link) {
return
Beta
;
}
return ;
};
Query Insights собирает телеметрию по каждому
оператору из вашего экземпляра
[Managed Postgres](/ru/products/managed-postgres/overview) и ранжирует каждый шаблон
запроса по степени влияния, чтобы вы могли перейти от "p99 постепенно растет" к "этот шаблон
сбрасывает промежуточные данные на диск", не покидая облачную консоль.
Данные поступают из [`pg_stat_ch`](https://github.com/clickhouse/pg_stat_ch),
расширения Postgres с открытым исходным кодом, которое передает счетчики по каждому оператору в
ClickHouse Cloud. Телеметрия нормализуется внутри Postgres до того, как покинет
базу данных: литералы удаляются и заменяются плейсхолдерами, поэтому
конкретные значения из ваших запросов никогда не попадают в поток телеметрии.
## Откройте Query insights
Откройте свой экземпляр Managed Postgres в облачной консоли и нажмите
**Query insights** на левой боковой панели. Страница разделена на четыре
области в том порядке, в котором вы, скорее всего, будете их использовать:
* **обзор** — сводка, в которой проверка состояния базы данных помещается на одном экране.
* Таблица **медленные шаблоны**, где ранжируются все шаблоны запросов, которые
выполнялись в вашей базе данных, с сортировкой по любому интересующему вас признаку.
* Панель **последние запросы**, в которой отдельные выполнения перечислены в обратном
хронологическом порядке.
* **Выдвижная панель сведений**, в которой собраны все счётчики для одного шаблона.
Используйте селектор **Time period** вверху, чтобы переключаться между последними 15
минутами, часом, днём, неделей или месяцем. Размер бакета агрегации
подбирается автоматически: 1-минутные бакеты для последних 15 минут или часа,
5-минутные — для последнего дня, а 1-часовые — для последней недели или месяца, чтобы
графики оставались отзывчивыми.
## Обзор
Обзор представляет собой сетку 3×2 из шести панелей:
| Панель | Что она показывает |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Queries / sec** | Объём запросов, приведённый к частоте за выбранный интервал. |
| **Query latency** | Среднее, p50, p95 и p99 на одном графике, чтобы было видно, когда хвост распределения начинает расходиться с медианой. |
| **Operations breakdown** | Кольцевая диаграмма, показывающая соотношение `SELECT`, `INSERT`, `UPDATE` и других операций, из которых фактически состоит ваша рабочая нагрузка. |
| **Rows returned / affected** | Общее количество строк, обработанных рабочей нагрузкой за выбранный интервал. |
| **Buffer hit ratio** | Кольцевая диаграмма соотношения попаданий в разделяемые блоки и чтений из них, а в легенде показано суммарное время CPU. |
| **Errors** | Общее количество ошибок с разбивкой по времени. |
Одного экрана достаточно, чтобы понять, здорова ли база данных. Для здорового экземпляра
характерна знакомая картина: коэффициент попаданий в буфер держится на уровне выше 90 %, объём запросов
меняется вместе с трафиком приложения, частота ошибок остаётся ровной или нулевой, а процентильные
задержки остаются близкими друг к другу.
## Медленные шаблоны
Когда сводка указывает на проблему, разбор обычно начинают с таблицы
шаблонов. По одной строке на каждый нормализованный шаблон запроса:
литералы удалены, поэтому все выполнения одного и того же оператора
сводятся в одну строку.
### Сортируйте по тому, что кажется подозрительным
По умолчанию таблица отсортирована по **Общему времени выполнения** по убыванию — при такой
сортировке шаблон вверху списка обычно и отвечает на вопрос «что обходится мне
дороже всего?». При этом сам по себе он не обязательно будет самым медленным шаблоном. Запрос,
который выполняется восемь миллионов раз в день по двенадцать миллисекунд, может
значить больше, чем тот, который выполнился один раз за три секунды.
Каждый вариант сортировки дает свой взгляд:
* **Общее время выполнения** — где база данных потратила больше всего фактического времени.
* **Время CPU** — шаблоны с высокой вычислительной нагрузкой.
* **Вызовы** — часто выполняющиеся шаблоны.
* **Ошибки** — повторяющиеся сбои.
* **Средняя / P50 / P95 / P99 / Максимальная задержка** — выбросы по процентилям.
* **Возвращено строк**, **Прочитано блоков**, **Попаданий блоков**, **Байты WAL** —
шаблоны, через которые прошло больше всего данных через движок, кэш или
журнал предзаписи.
Нажмите кнопку **Columns**, чтобы показать или скрыть дополнительные столбцы.
Таблица шаблонов содержит 19 столбцов, включая разбиение по
процентилям, коэффициент попаданий в кэш и время CPU для каждого шаблона.
### Сузьте таблицу
Отфильтруйте таблицу по интересующему вас срезу рабочей нагрузки:
* **База данных**
* **Пользователь**
* **Операция** (`SELECT`, `INSERT`, `UPDATE`, `DELETE`, …)
* **Приложение** — `application_name` из строки подключения
«Покажи мне только то, что делает сервис orders в базе `sales`»
превращается в два выпадающих списка. Значения фильтров автоматически
заполняются на основе того, что фактически выполнялось в вашем
экземпляре.
## Последние запросы
Под таблицей шаблонов панель **Последние запросы** показывает отдельные
выполнения в обратном хронологическом порядке — одна строка на каждый выполненный
оператор, а не на каждый шаблон. Используйте её, когда нужен поток
необработанных событий, а не агрегированные данные, например чтобы выборочно проверить,
что исправление применилось, или найти точный момент возникновения ошибки.
По умолчанию отображаются столбцы Time, Operation, Query, Duration, Rows,
Database, User и Blks read. Откройте средство выбора **Columns**, чтобы добавить
Application, Blks hit, CPU user, CPU sys и PID. Таблица поддерживает
те же фильтры Database, User, Operation и Application, что и
таблица шаблонов, а также сортировку по Time, Duration, Rows, Blks read и
CPU time.
Нажмите любую строку, чтобы открыть ту же выдвижную панель сведений, что и у таблицы шаблонов,
но только для шаблона этого конкретного выполнения.
## Выдвижная панель сведений
Нажмите любую строку в таблице шаблонов или недавних запросов, и справа
откроется выдвижная панель **Сведения о запросе**. На этой панели
собраны все выполнения данного шаблона за выбранный диапазон времени и
агрегированы счётчики, которые помогают понять, почему он работает медленно.
Панель представляет собой одну прокручиваемую область с пятью разделами:
* **Шаблон запроса** — нормализованный SQL, в котором литералы заменены на `$1`,
`$2`, …, и кнопка копирования в буфер обмена.
* **Агрегированное использование ресурсов** — сетка из 13 карточек
статистики, включающая общее число вызовов, среднюю/P95/P99/максимальную
задержку, общее время выполнения, число возвращённых строк, долю попаданий
в кэш, число прочитанных блоков, число блоков с попаданием в кэш, время CPU, байты WAL и ошибки.
* **Контекст запроса** — база данных, пользователь, операция и приложение,
из которых пришёл этот шаблон.
* **Примечательные выполнения** — ошибки, необычно медленные запуски и
выполнения с большим объёмом результатов, показанные перед полным списком недавних.
* **Недавние выполнения** — отдельные запуски одного и того же шаблона
со счётчиками для каждого выполнения.
### Счетчики по каждому выполнению
Разверните одно из недавних выполнений, и вы увидите счетчики, которые
точно показывают, куда ушло время:
* **Общие блоки** — прочитанные и найденные в кэше показываются всегда; записанные и измененные
показываются, только если их значение не равно нулю.
* **Операции с локальными и временными блоками** — ненулевые операции с временными блоками означают, что sort или
hash были выгружены на диск.
* **Время чтения / записи** — время ввода-вывода, отдельно от времени CPU.
* **Время CPU** — пользовательское и системное, по отдельности.
* **Параллельные воркеры** — запланированные и фактически запущенные.
* **JIT** — общее время JIT-компиляции и количество функций.
* **WAL** — количество байтов и записей.
Все, что нужно для диагностики медленного паттерна, собрано в одном
месте, на одном экране.
## API Query Insights
Та же телеметрия доступна программно через
[ClickHouse Cloud OpenAPI](/ru/products/managed-postgres/openapi#query-insights).
Таблица [медленные шаблоны](#slow-patterns) сопоставлена с
конечной точкой
[получения списка шаблонов медленных запросов](/ru/api-reference/organization/get-list-of-available-organizations#tag/Postgres/operation/slowQueryPatternsGetList),
а [выдвижная панель сведений](#detail) — с
конечной точкой
[получения шаблона медленного запроса](/ru/api-reference/organization/get-list-of-available-organizations#tag/Postgres/operation/slowQueryPatternGet),
которая возвращает агрегированные метрики одного шаблона вместе с его
последними выполнениями.
## Как это работает
### Нормализация в Postgres до передачи по сети
`pg_stat_ch` перехватывает фазу parse-analyze, заменяет каждый литерал на
плейсхолдер (`$1`, `$2`, …) и кэширует получившийся шаблон в
отдельном LRU-кэше для каждого backend-соединения с ключом по `queryid`. Когда выполнение
оператора завершается, именно этот кэшированный шаблон прикрепляется к событию. Точный
оператор со значениями никогда не покидает базу данных.
### Не мешает работе базы данных
Продьюсер добавляет примерно 3% накладных расходов на каждый оператор. Путь добавления в очередь
использует неблокирующий try-lock для кольцевого буфера в общей памяти. При
перегрузке расширение отбрасывает события, увеличивая Counter, вместо того
чтобы создавать обратное давление на Postgres.
### Сырые события, а не агрегаты
`pg_stat_ch` генерирует по одному сырому событию для каждого выполненного оператора (как верхнего уровня, так и
вложенного) с учетом сэмплирования. Все перцентили, ранжирование и разбивки
в интерфейсе — это запросы к ClickHouse по тому же потоку событий.
### Тот же движок, которым пользуются наши клиенты
Бэкенд Insights — это [ClickHouse Cloud](/ru/products/cloud/getting-started/intro).
Телеметрия по каждому запросу от загруженного экземпляра Postgres — это миллионы строк
в день; столбцовое сжатие позволяет недорого хранить детальные данные по каждому выполнению
месяцами, а агрегации по миллиардам строк, выполняющиеся за доли секунды, сохраняют
интерфейс отзывчивым, пока вы анализируете данные за неделю или месяц.
### С открытым исходным кодом
`pg_stat_ch` распространяется по лицензии Apache 2.0. Запускайте его с любым Postgres и отправляйте данные в любой
ClickHouse. Исходный код и баг-репорты — на
[github.com/clickhouse/pg\_stat\_ch](https://github.com/clickhouse/pg_stat_ch).
## Связанные страницы
* [Панель мониторинга](/ru/products/managed-postgres/monitoring/dashboard) — встроенные диаграммы ресурсов и активности
* [Конечная точка Prometheus](/ru/products/managed-postgres/monitoring/prometheus) — собирайте метрики уровня хоста в собственный стек обсервабилити
* [Managed Postgres OpenAPI](/ru/products/managed-postgres/openapi#query-insights) — программно запрашивайте медленные шаблоны и недавние выполнения
* [Расширения](/ru/products/managed-postgres/extensions) — расширения, доступные в экземплярах Managed Postgres
* [`pg_stat_ch` on GitHub](https://github.com/clickhouse/pg_stat_ch) — расширение с открытым исходным кодом, лежащее в основе Query Insights