Метрики по pg_stat_statements собираются telegraf-ом в InfluxDB. Continues query подготавливает данные - сохраняет non_negative_diffrence от метрик в отдельный measurement. Так монотонно растущие метрики становятся дельтами за минуту. Grafana визуализирует.

Напишу статью про настройку. Сдалали с коллегами хороший быстрый отчет по запросам

а потом в инфлюкс?

куда хочешь. можно в инфлюкс, можно в промик

Обновил

Почитать бы сейчас

а в чем задача то? Почему именно прометеусом нужно собирать?

А ты про эту церковь 😂

Спасибо

Коллеги, добрый день!
Столкнулся с проблемой: HTTP-запросы из JMeter'а не всегда доходят до цели. Смотрел логи шины, через которую идёт общение с нагружаемой машиной, - сообщение не появляется. Какие могут быть причины? Пока что на ум приходят:
1) проблемы с интернетом (маловероятно),
2) проблемы с шиной (высокая вероятность),
3) перегруз целевой машины (дашборд с node exporter'ом показывает использование 75% CPU, 87% RAM, 180% Sys Load 5m avg для восьмиядерного процессора).

А в логах JMeter есть ошибки?

Нет ошибок. Если потоки не убить кнопкой "Stop", то они так и будут висеть в ожидании ответа, которого никогда не будет.

Если тест выполняется через Интернет, то может быть защита от DDoS хостинга, вас забанила пока

Нет, это сеть заказчика, доступы есть.

Решения не знаю.

Можно настроить максимальное время ожидания ответа. В http request defaults.

Response Timeout
https://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request_Defaults

Чтобы не висели потоки

Возможно, вы тестирует через прокси. У меня бывало такое. И прокси завис. Тогда надо отключить прокси

Fiddler/Charles/...

180 la для восьмиголов это перегруз по ио

Спасибо. Думаю, проблема в шине/тачке, т.к. до этого проблем с сетью не наблюдалось.

Можно поподробнее, как считать la для многоядерных машин и что принять за норму? Читал https://scoutapm.com/blog/understanding-load-averages - я так понял, что чем больше ядер, тем большее значение допустимо.