Как за 2 часа предсказать инцидент производительности СУБД PostgreSQL⁠⁠

Оригинал — на основном техническом канале (Возможны правки и дополнения).

Сокращенная версия, полный вариант статьи:

О применении метода сравнения профилей производительности для прогнозирования инцидентов СУБД PostgreSQL

Как научиться предсказывать замедление производительности СУБД PostgreSQL за 2 часа до их начала?

(Эксперимент по поиску «тихих признаков» будущей бури)

Вступление: что проверяется

Представьте, что вы следите за пульсом человека. Если пульс резко меняется — это повод насторожиться до того, как случится инфаркт.

Чтобы выяснить возможность подобных прогнозов, в течении 2-х месяцев проводились серии экспериментов объединённых одной целью : можно ли заметить изменения в «пульсе» СУБД до того, как она начнет заметно тормозить.

ℹ️В результате выработалась методология - каждую минуту смотреть на поведение базы данных и сравнивать его с «идеальным» поведением в спокойный период. Если поведение сильно отличается — система бьет тревогу.

Итоговый тест был проведён на реальных данных, длительностью - одни сутки.

Как это сделано (очень упрощённо)

📋Выбор эталона:

• Один час, когда база работала нормально. Запомнить "пульс" или скорее «показатели ЭКГ».

📋Наблюдение:

• Каждую минуту - сравнение текущего "пульса" СУБД с эталоном.

📋Статус:

• Если отклонение небольшое — зеленое свет «NORMAL».

• Если среднее — жёлтый свет «WARNING».

• Если сильное — красный «CRITICAL».

📋Если начался инцидент или СУБД восстанавливается после инцидента:

• Устанавливается статус «INCIDENT».

Главные цифры

ℹ️За сутки произошло 13 инцидентов. Длительностью от 9 минут до полутора часов.

💥ГЛАВНЫЙ РЕЗУЛЬТАТ: Система обнаружила все 13 сбоев заранее!💥

☑️В большинстве случаев предупреждение приходило за 1–2 часа до начала проблем.

ℹ️В "худшем" случае (один внезапный сбой) — система предупредила за 15–20 минут(что тоже очень много, чтобы успеть принять меры).

💥Ни один сбой не прошел незамеченным.💥

Как это выглядело в жизни (примеры из отчета)

• Случай №1 (долгий сбой в 3 часа ночи). В 1:48 ночи система сказала: «Внимание, что-то не так». В 2:48 она закричала: «Красный уровень!». А сам сбой начался только в 2:49. То есть у инженера было целых 60 минут, чтобы подготовиться или перезапустить сервер до того, как всё сломалось.

• Случай №2 (утренний сбой). Первое «Внимание» прозвучало за 142 минуты до сбоя, а «Красный уровень» — за 115 минут. Это невероятно раннее обнаружение.

• Случай №3 (внезапный сбой днём). Здесь ситуация развивалась стремительно. От первого «Внимания» до сбоя прошло всего 19 минут.

Почему это лучше, чем старые методы?

Раньше мы смотрели только на вероятность сбоя (как на прогноз погоды: «завтра дождь 50%»). Но этот метод смотрит на профиль работы СУБД.

Представьте: вы едете в машине. Прогноз говорит: «вероятность поломки 0%». Но вы вдруг слышите странный стук под капотом. Вы еще не сломались, но стук есть!

ℹ️Система как раз ловит этот «стук» — структурные изменения, которые не видны в сухих цифрах вероятности. В одном из случаев она забила тревогу «Красный уровень!», хотя старый метод показывал «Риск равен нулю».

Есть ли у метода минусы?

ℹ️Да, бывают ложные тревоги. Иногда система говорит «Внимание», но сбой так и не наступает. Однако такие ложные сигналы длятся всего несколько минут и быстро проходят. Это как ложное срабатывание сигнализации — лучше пусть она сработает лишний раз, чем пропустит реальную угрозу.

Практические выводы

1. 🟡Статус WARNING (жёлтый) — это сигнал «проверь всё». Есть от 30 до 60 минут, чтобы осмотреться.

2. 🔴Статус CRITICAL (красный) — это сигнал «действуй сейчас». Есть 15–30 минут, чтобы подготовиться .

3. 🟤Возврат в статус NORMAL (зеленый) после сбоя — это гарантия, что СУБД восстановилась и можно выдохнуть.

Итог

ℹ️Метод сравнения «пульса» базы данных с её нормальным состоянием — это мощный инструмент раннего предупреждения. Он дает инженерам драгоценное время (от 15 минут до 2 часов), чтобы принять меры , вместо того чтобы героически исправлять его последствия.