PostgreSQL, RED, Golden Signals: руководство к действию

[rinace]

По поводу Duration, есть пара вопросов:
1)

total_time. Это поле показывает в миллисекундах время выполнения (включая ожидание) для каждого типа запросов.

А разве поле total_time показывает не общее время выполнения запроса?

2) Получить историю времени выполнения конкретного запроса нельзя?

Далее.

если ваш Postgres злоупотребляет ошибками, idle транзакциями или блокировками, то Weaponry подскажет что делать.

А можно примеры подсказок?

[lesovsky]

1) total_time показывает сумму всех времен выполнения этого запроса, условно говоря если запрос выполняется ~1ms и выполнялся 1000 раз, то в total time будет ~1000 (ms).
2) Через pg_stat_statements увы нет, нельзя. там только агрегаты. Точное время выполнения конкретного запроса можно получить через логи (при условии что логирование настроено).
3) Пока подсказки довольно простые и просто указывают на наличие проблемы и пути дальнейшего действий что с этим делать. Например для idle транзакций устранить их в приложении, включить автоматическое завершение idle транзакций по таймауту и т.д.

[rinace]

3) Пока подсказки довольно простые

ну вот например по блокировкам и ожиданиям, какие будут подсказки?
Можно увидеть, что один запрос находится в ожидании и заблокирован другим запросом?

ну например есть у меня запрос. Всегда выполнялся пусть 1 секунду, а сейчас 5 секунд. Почему?
Дашбоард показанный в статье поможет?

[lesovsky]

> ну вот например по блокировкам и ожиданиям, какие будут подсказки?
сначала посмотрим включен ли log_lock_waits, если не включен то скажем включить и через некоторое время проверить логи. Если уже включен, скажем смотреть логи на предмет waiting и дальше инспектировать приложение и фиксить там.

> Можно увидеть, что один запрос находится в ожидании и заблокирован другим запросом?
Не, пока такого нет

> ну например есть у меня запрос. Всегда выполнялся пусть 1 секунду, а сейчас 5 секунд. Почему?
Дашбоард показанный в статье поможет?

Если запрос всего один, то есть вероятность что он потеряется на фоне других (при большом rate). Если таких запросов много, то вы пятикратное увеличение времени вы увидите в durations. Ну а дальше надо идти в отдельный дашборд в котором собрана стата по запросам и там смотреть что за тип запросов стал выполняться дольше (а затем explain и вот это все).
Задача RED и Golden Signals дать способ быстро ответить на вопрос, все хорошо с сервисом. Детали работы сервиса уже покрываются отдельными метриками.

[YAKOROLEVAZAMKA]

Спасибо, очень интересно — аж сразу захотелось реализовать подобное (на работе как раз postgres) :)
Есть только один вопрос — что есмь RED и Golden Signals, где это брать и с чем это едят? Если есть инфа для кранов нубов — то поделитесь, пожалуйста :)

Зы. гуглить-то, я, теоретически, умею, но хотелось бы услышать совета от профессионалов дабы сэкономить вагончик времени :) заранее спасибо!

[lesovsky]

RED и Golden Signals это набор метрик для поверхностной оценки состояния сервиса. Первым появился GS в недрах гугла, почитать можно в SRE Book, RED это уже наложение USE метода на GS. Суть методов в том что сервис обрабатывает запросы, часть из них может быть ошибочными, и запросы обрабатываются с разными временем. Получается что накладывая метрики на то как обрабатываются запросы, мы можем оценить насколько хорошо справляется наш сервис со своей работой или нет. Если вы не знакомы с темой рекомендую начать с приведенных ссылок.

[YAKOROLEVAZAMKA]

Большое спасибо, обязательно ознакомлюсь!
Просто N-ое время назад из компании уволился DevOps, при котором была графана мониторящая прод-сервер (там как раз показывались аналогичные метрики), что мне очень нравилось. Соответственно я думаю как бы восстановить утерянное (хотя бы для себя :)

[polarnik]

Алексей, спасибо за полезные запросы к pg_stat_activity.
Добавлю, что при наличии микросервисов удобно группировать метрики из pg_stat_activity по usename. Чтобы сопоставлять "idle in transaction" с конкретным сервисом.

[polarnik]

И дополнительно можно группировать pg_stat_activity по ключу

md5(query)::uuid::varchar(100) as query_md5

А если места не жалко, то можно просто по

left(regexp_replace(query, '\\r|\\n|\\t|\\s+', ' ', 'g'), 1000) query

Тогда для "idle in transaction" накапливается статистика о запросах, после которых транзакция зависла. md5 можно сопоставить с md5 из pg_stat_statements. А query сам по себе интересен. В МакроСервисах кода много и текст query может быстрее привести к месту в коде, где транзакции обрываются.

[lesovsky]

Согласен с вами, когда собираешь метрики на основе pg_stat_activity там много чего чем можно дополнительно обогатить метрику )))

[dima_sheihin]

Алексей, спасибо статью и свое виденье
Для глубокого анализа происходящего можно поставить расширение pg_profile по средствам которого можно поднять историю происходящего и детально разбираться Андрей рассказывает как это работает