DevOps головного мозна

В последние недели большую часть времени мне приходится заниматься мониторингом PostgreSQL. Типичные болевые точки:  - Запросы выполняются долго  - Код написан не нами, и переписывем "по возможности" Куда смотреть понимания нет, поэтому хотел бы рассказать о своем опыте, и том минимуме который стоит замониторить. В первую очередь необходимо мониторить кол-во соединений к БД, как активных, так и idle. Общее кол-во соединений в целом можно и через кол-во процессов мониторить, а активные через представление pg_stat_database. Через это же представление мониторим кол-во записей по типам(тут могу немного ошибаться в терминологии, или не правильно выразиться, но речь идет о tuples), кол-во commit rollback операций.   Эти метрики позволят нам оценить как минимум нагрузку и кол-во операций в БД, так же понадобятся в сравнительном анализе(при выполнении определенных изменений в конфигурации, в рамках нескольких итераций отследить например кол-во операций и сопоставить с остальными матриками) Следующим показателем у нас будут блокировки по типам, эти данные берем из pg_locks, по этим метрикам больше вопросов будет к разработчикам, в плане оптимизации запросов с целью избегания блокировок. И последним будет представление pg_stat_statements, из которого мы берем информацию о кол-ве промахов мимо кэша или work_mem например - это прям явные сигналы к тому что необходимо оптимизировать те или иные параметры в postgresql.conf И чуть не забыл - это представление pg_stat_all_tables из которого можно получить информацию о кол-ве последовательных сканирований и сканирований таблице по индексу, тоже очень важный параметр на который стоит заострять внимание разработчиков(или DBA если они у Вас есть. Хотя если они у Вас есть - представленная мною информация не очень пригодится, т.к. они и так лучше меня знают что надо делать и куда смотреть) --- Подписывайтесь на наш телеграм канал, в котором можно узнать все самое интересное первым - t.me/...ins