Обновить
124
Алексей Лесовский@lesovsky

Разработка инструментов для PostgreSQL

95
Подписчики
Отправить сообщение
пгцентр не совсем про мониторинг, основная цель это показать/посмотреть что сейчас происходит в постгресе, то есть это скорее дополнение к уже имеющемуся мониторингу. Есть конечно функция для дампа статы, но у нее тоже нет задачи заменить мониторинг.
да, можно фильтровать по любому полю… хоткей как в less — "/", есть поддержка регекспов.
например в приаттаченом скринкасте, демонстрируется фильтрация по базе (celldb) и там показываются statements только для этой базы
> В чем принципиальная разница с github.com/julmon/pg_activity
принципиальной разницы нет… подключаемся к постгресу, селектим стату, показываем юзеру.

Разница есть в наборе фич, pgcenter показывает не только активность, но и стату по остальным вьюхам… таблицы, индексы, функции, размеры, вакуумы, репликация, по pg_stat_statements аж 5 скринов, есть системная стата cpu/mem/swap/iostat/nicstat. просмотр и правка конфигов, просмотр логов (пгцентр сам ищет путь, не надо держать их в уме) и пр. кстати psql можно прям из пгцентра запустить если хочется что-то руками поделать (не надо вторую консоль открывать)

> Там табличка более презентабельно раскрашена, как по мне. Глазу легче.
наверно… я про цвета еще не думал, но вот например в новом iostat добавили поддержку цветов, а я ее по старинке отключаю ))) так что на вкус и цвет…

> Я так понимаю, что нужны права суперюзера на исследуемую базу?
да частично нужны права, чтобы смотреть текущие запросы например, но можно дать права роли pg_monitor или как там её и оно должно работать.
Спасибо за увлекательное чтиво.
Попробуйте дернуть соотв. метрику через zabbix_get и проверьте таймауты у агента и сервера (тут выше в коментариях уже упоминали об этом)
Привет! добавьте ваш ключ -N в параметры вызова iostat в iostat-collect.sh.
ыыы опередил меня)))
коллеги, вместо грепанья /proc/net/dev можно использовать nicstat от того же BG.
Для production окружения использовать BDR не стоит. Лучше использовать проверенные временем решения как pgpool.
OKmeter хорош да, постгресовый плагин там очень годный за счет агрегации данных с pg_stat_statements — очень хорошо видно запросы которые вдруг начинают выпирать (cpu/disk usage, row returned).
image
Про системную часть можете глянуть презентацию www.slideshare.net/alexeylesovsky/linux-tuning-for-postgresql-at-secon-2015
Там тезисно, но общие направления куда копать вполне понятны.
куку)) обратите внимание на дату публикации поста, уже почти полтора года прошло, неудивительно что многое могло поменяться.
да, проект еще не достаточно mature поэтому многое еще может и будет меняться.
Про какую репликацию вы говорите? Репликацию таблиц в XL/XC или нативную потоковую репликацию что изначально есть в постгресе?
Если про первое, то имхо это вобще сомнительная идея (с точки зрения производительности) держать копию таблицы на всех узлах кластера. Если про второе (подпирать каждую датаноду своим стендбаем), то тут репликация совсем не гарантирует консистентность (т.к. нет нативного мониторинга отвалов нод и авто-файловеров) особенно при шардинге таблиц.
веселье начинается с момента когда отвалилась нода с данными и надо ее вернуть на место.
Спасибо, познавательно.
Скажите, чем вас не устроил iostat, раз вы решили написать blktop?
> Kто из системных администраторов не знает об этом?

я не знал))) все как-то консолью, да консолью
о отличный комбайн
pg_monz совсем не умеет мониторить потоковую репликацию и для LLD используются доп.скрипты — лишняя сущность имхо, есть разница в кол-ве отслеживаемых параметров (детальная табличная статистика, параметры конфига pg, объем записи WAL и пр.). Ну и есть пара мелких сугубу субъективных претензий (именование итемов в шаблоне, кол-во и составление графиков, триггеры).

p.s. и еще у меня есть PG_CONN_TOTAL_PCT (см. текст статьи) — универсальная штука с которой нет необходимости лезть в конфиг постгреса и смотреть там max_connections. ))

Информация

В рейтинге
Не участвует
Откуда
Екатеринбург, Свердловская обл., Россия
Зарегистрирован
Активность