sfalkongm Sep 23 2019 at 18:28

postgres_exporter и мониторинг экземпляров PostgreSQL с несколькими БД

10 min

33K

PostgreSQL*

From sandbox

+10

Comments 12

Sleuthhound Sep 23 2019 at 19:35

Есть же замечательная штука PMM — Percona Monitoring and Management, который под капотом содержит тот же Prometheus + еще кучку всего и из коробки умеет мониторить MySQL, Pg и MongoDB

sfalkongm Sep 23 2019 at 20:11

Возможно. Ещё есть mamonsu для zabbix, а так же это можно делать скриптами и вероятно есть ещё много разных инструментов… Но к заметке выше это не имеет ни какого отношения.
Я не сравнивал решения, а разобрал вполне конкретную ситуацию и не более того.

mcleod095 Sep 23 2019 at 20:40

То есть если у меня уже стоит prometheus и даже если поднят тот же consul, то предполагается что я буду ставить дополнительно еще одну систему мониторинга отдельно для БД в виде PMM?
хотя PMM это тот же prometheus + consul + клиент для регистрации и куча хороших шаблонов.
Кстати шаблоны percona не скрывает и они лежат в открытом доступе. Для себя я взял их за основу, раскатил exporter и донастроил шаблоны под себя.

aleksey_beloliptsev Sep 27 2019 at 10:29

У PMM есть хорошая фича по анализу запросов для разных БД — MySQL, Mongo и начиная с релиза 2.0 добавили Postgres. Кстати, если я не ошибаюсь, данный экспортер не умеет в метрики по SQL запросам(pg_stat_statements).

sfalkongm Sep 27 2019 at 11:54

Последнее утверждение, не очень понятно. О каком экспортере речь?
В простом случае, когда у Вас один экземпляр и одна БД, с описанным в статье экспортером, вообще нет никаких проблем. Он работает, без особых, нареканий.
Но самое интересное начинается когда баз в одном экземпляре более одной, а каких именно и почему, описано в статье.

Vitaly2606 Sep 23 2019 at 20:28

Для информации: есть еще pgwatch2, я остановился на этом решении.
github.com/cybertec-postgresql/pgwatch2

Главный плюс (по моему мнению) нет необходимости ставить каких либо агентов/экспортёров на хосты PG.
Остальные возможности, указаны в описании репозитория.

sfalkongm Sep 23 2019 at 21:50

Может показаться, что я «топлю» за использование postgres_exporter… Но все таки отмечу, что он так же не требует установки на одном узле с PG. И в какой то мере, безопаснее ставить экспортер ближе к prometheus так как postgres_exporter не умеет шифровать трафик до prometheus, но может общаться с PG по ssl

fessmage Sep 24 2019 at 10:32

Насчет отсутствия авторизации и TLS — это общее место для всех prometheus exporter и это осознанная позиция их разработчиков. Они считают что экспортер должен заниматься только непосредственное собственной задачей, обеспечение защищенности канала предоставляется на усмотрение пользователя. И нельзя сказать что они не правы — ведь в ином случае код каждого из сотен экспортеров должен был включать работу с авторизацией и TLS.
По-умолчанию считается, что на хосте который мы мониторим должна быть private network и экспортер должен слушать интерфейс внутренней сети — в этом случае необходимость доп. защиты отсутствует.
Если же возможности такой нет, а у нас доступен только публичный адрес, то можно сделать две вещи:

поставить экспортер на локальный интерфейсе, а на публичный адрес поставить nginx, который будет по определенному location проксировать запрос на экспортер, плюс обеспечивать tls и авторизацию
поставить экспортер на локальный интерфейс, а на публичный адрес поставить telegraf (который умеет и в авторизацию и в tls, а также может собой заменить и некоторые экспортеры), а уже telegraf заставить собирать данные с prometheus экспортеров хоста и отдавать их же в prometheus формате.
На текущий момент я использую последний вариант — на инстанс ставится telegraf, все prometheus экспортеры подключаются к нему локально, а prometheus сервер стучится только на один target хоста — в telegraf.

Sleuthhound Sep 24 2019 at 13:48

Позиция может и верная, но в результате чтобы мониторить пяток сервисов нужно поставить на сервер 5 разных экспортеров, да еще потом воткнуть и настроить тот же nginx (к примеру) и получается гора софта и гора настроек — усложнение на ровном месте.

gecube Dec 20 2019 at 16:00

Альтернативный вариант — использовать решения all-in-one вроде сборщика telegraf или системы мониторинга netdata.

chemtech May 12 2020 at 08:21

sfalkongm подскажите почему pg_stat_database_blk_read_time у вас по нулям? от чего она зависит?

sfalkongm May 12 2020 at 09:31

Счетчик на нулях, так как track_io_timing (включает замер времени операций ввода/вывода) по-умолчанию выключен, на демонстрационном стенде я его не включил.

Show the best of all time