От мониторинга к оптимизации: как предупреждение «Patroni unhealthy» указало на исчерпание ресурсов PostgreSQ В ходе эксплуатации кластера PostgreSQL под управлением Patroni система мониторинга зафиксировала эпизодические переходы мастер-узла в состояние unhealthy — при том, что уже через минуту статус восстанавливался. Первичный анализ указывал на слишком низкий statement_timeout, но глобальная конфигурация PostgreSQL и файлы Patroni не содержали этого параметра. Детальное расследование, охватившее логи, нагрузку на сервер и даже исходный код Patroni, позволило не только найти скрытый жёстко заданный тайм-аут (2 секунды), но и установить истинную причину нестабильности — высокую нагрузку на СУБД, при которой даже системные запросы перестали укладываться в этот лимит. В этой статье мы разбираем ход диагностики, ключевые выводы и объясняем, почему «тонкая настройка» Patroni в данном случае была бессмысленна без оптимизации ресурсов базы данных. https://dzen.ru/a/ab5KM7C2knFueV5z