Мониторинг PosgreSQL

Современная СУБД это фактически кирпич в плане надежности, по сравнению с остальными частями ИТ-системы. Практически все ошибки связанные с СУБД происходят из-за данных внутри: смена их структруры, обновление, удаление - вот это все.

Очень очень редко когда дело доходит до битых данных или сбоев в самой СУБД.

Главных метрик для СУБД всего две: свободное место на диске и скорость работы запросов.

Первое мониторится элементарно, второе - сильно индивидуально и привязано к логике работы конкретной системы. Бывает что запрос выполняется сутками, когда идет формирование каких-то сложных отчетов.

gpt-паста vs gpt-паста?
*ответ из gpt

Есть ещё метрика - отсутствие connection refused при попытке подключиться.

Ну а к общесистемным метрикам, к которым относится место на диске, стоит всё-таки добавить ещё load average и оперативную память/свап.

Есть ещё метрика - отсутствие connection refused при попытке подключиться.

Вообще-то везде пулы подключений, это когда постоянно открыто несколько соединений к базе. Поэтому «connection refused» это либо сеть либо исчерпание пула подключений, те это внешние факторы а не сама СУБД.

Ну а к общесистемным метрикам, к которым относится место на диске, стоит всё-таки добавить ещё load average и оперативную память/свап.

Они будут сильно меняться в зависимости от конкретных действий. То же построение индексов дает 100% нагрузку на CPU и память, но это же не показатель что с базой что-то не так?

Поэтому «connection refused» это либо сеть либо исчерпание пула подключений, те это внешние факторы а не сама СУБД.

Да нет, это ещё может быть тупо упавший сервер базы. Хотя в случае с постгресом (про который тема) это наверно намного менее вероятно чем с всеми любимым innodb у которого ассерты на данные в файлах. Но всё-таки не стоит исключать.

Они будут сильно меняться в зависимости от конкретных действий. То же построение индексов дает 100% нагрузку на CPU и память, но это же не показатель что с базой что-то не так?

100% это одно ядро или все? Если одно то это и не повод беспокоиться, а если все - постгрес умеет перестраивать индекс одной таблицы параллельно на многих ядрах что ли?

А вообще надо сиотреть не на сиюминутные показатели а на общие тенденции, и при необходимости учитывать какие-то особенные ситуации.

Да нет, это ещё может быть тупо упавший сервер базы.

Тогда будет не connection refused а connection timeout. Но смысла мониторить падение нет, поскольку его и так будет видно сразу - по вою от пользователей. Плюс это совсем уж залет, если на проде.

100% это одно ядро или все?

Думаю очевидно что это зависит от настройки и конкретных действий. Но я вообще про другое: для СУБД это норма что происходят переодические перегрузки по CPU, памяти и операциям с ввода-вывода. Поэтому мониторинг загрузки ресурсов ничего особо не даст.

Timeout будет если упала железка, а если упал именно демон то refused. Впрочем timeout тоже надо бы мониторить, да.

Плюс это совсем уж залет, если на проде.

Согласен, но представь что будет если у тебя случился такой залёт, а ты о нём ещё и узнаешь только спустя сутки, а всякие техподдержки (если они есть) будут отвечать юзерам дефолтной отмазкой «у нас тех работы, зайдите через час».

Но смысла мониторить падение нет, поскольку его и так будет видно сразу - по вою от пользователей.

Вой от пользователей тоже требуется мониторить, это не дефолт. А у некоторых компаний это перманентное состояние (по другим причинам), и придётся ещё и отличать вой из-за падения от обычного воя.

для СУБД это норма что происходят переодические перегрузки по CPU, памяти и операциям с ввода-вывода. Поэтому мониторинг загрузки ресурсов ничего особо не даст.

Одно дело периодические а другое когда среднедневная (допустим с 8 утра до полуночи, чтобы ночные тех работы исключить) нагрузка изменилась.

что будет если у тебя случился такой залёт, а ты о нём ещё и узнаешь только спустя сутки, а всякие техподдержки (если они есть) будут отвечать юзерам дефолтной отмазкой «у нас тех работы, зайдите через час».

Думаю примерно на пятом обращении кто-то из техподдержки все же соизволит посмотреть что там с системой, доступ у них обычно есть. Так что в историю с сутками не верю, полчаса максимум от падения до звонка админу.

Но тут проблема-то в другом: каждый сбой СУБД (те нештатная остановка) на проде это гарантированная проверка целостности данных и шанс попасть на их потерю. Поэтому я и назвал это залетом. А дальше может быть очень неприятный процесс восстановления из бекапа.

Одно дело периодические а другое когда среднедневная (допустим с 8 утра до полуночи, чтобы ночные тех работы исключить) нагрузка изменилась.

Так это уже статистика (причем по системе в целом), которую еще надо уметь собирать. К метрикам производительности самой СУБД это отношения не имеет.

100% это одно ядро или все?

Наверно, бывают случаи превышения нормальных показателей LA и без высокой вычислительной нагрузки на CPU?