kznalp

В рамках проекта pg_expecto разработана и внедрена система прогнозирования риска возникновения инцидентов производительности на основе цепей Маркова.

Реализация представляет собой полноценное решение, адаптированное к потоковым данным и способное к самонастройке.

Постановка задачи

Производительность СУБД PostgreSQL подвержена влиянию множества факторов, включая характер нагрузки, состояние операционной системы и внутренние события ожидания.

Традиционные подходы к мониторингу, как правило, реагируют на уже возникшие проблемы, тогда как задача проактивного обнаружения предвестников сбоев требует более глубокого анализа динамики системы.

В основу предлагаемого решения положена идея дискретизации непрерывных метрик производительности в конечное множество состояний, переходы между которыми описываются марковским процессом. Это позволяет моделировать эволюцию состояния системы во времени и оценивать вероятности неблагоприятных исходов.

Формализация состояния системы

Непрерывные метрики – операционная скорость, время ожиданий и корреляция между ними – преобразуются в дискретное пространство из 189 состояний.

Каждое состояние характеризуется тремя параметрами:

• коэффициентом корреляции (21 градация от –1,0 до +1,0 с шагом 0,1),

• трендом операционной скорости

• трендом времени ожиданий (каждый принимает значения –1, 0, +1).

Такая дискретизация обеспечивает баланс между детализацией модели и вычислительной эффективностью.

Архитектура системы

Система построена по многослойному принципу:

Слой данных

Включает таблицы:

• хранения переходов (transition_log)

• накопленных частот (markov_frequencies)

• матрицы вероятностей (markov_probabilities)

• поглощающей матрицы для многошагового прогноза (markov_absorbing).

Отдельно выделены таблицы:

• конфигурации (markov_config), справочник состояний (state_descriptions) и динамический список критических состояний (critical_states).

Слой обучения

Реализует пошаговое обновление модели с частотой одна минута.

На каждом шаге выполняются:

• получение текущих метрик,

• вычисление идентификатора состояния,

• логирование перехода,

• обновление частот ,

• при необходимости, применение забывания.

Слой прогнозирования

Предоставляет функции для оценки риска на заданном горизонте.

Ключевая функция mchain_predict_risk_k_v2 вычисляет вероятность хотя бы одного попадания в критическое множество за k шагов.

Слой оценки

Включает механизмы расчёта достоверности прогнозов и суточных метрик качества.

Обучение модели и адаптивное забывание

Обучение происходит в реальном времени на потоке данных. По мере поступления новых наблюдений обновляются частоты переходов и пересчитываются вероятности. Ключевой механизм, обеспечивающий адаптацию к изменению характера нагрузки, – забывание.

Коэффициент забывания α определяет скорость, с которой устаревающие наблюдения теряют вес.

В адаптивном режиме α вычисляется по формуле:

α(t) = max(min_alpha, base_alpha · exp(-days_since_last_incident / half_life))

где days_since_last_incident – время, прошедшее с последнего попадания в критическое состояние.

Такой подход позволяет ускорить забывание после инцидентов и замедлить его в стабильные периоды. Дополнительно введён stability_factor, корректирующий α в зависимости от нестабильности вероятностей.

Важным условием применения забывания является достаточность накопленных данных. Функция mchain_check_sufficiency проверяет, что общее число переходов превышает порог min_transitions_for_forgetting (по умолчанию 5000).

Прогнозирование риска

Прогноз риска строится на основе текущего состояния системы и матрицы вероятностей переходов. Для одношагового прогноза используется прямая сумма вероятностей перехода в критические состояния.

Многошаговый прогноз (mchain_predict_risk_k_v2) реализует итеративное умножение вектора распределения вероятностей на матрицу переходов. На каждом шаге вероятности, попавшие в критические состояния, накапливаются в значении риска, а затем обнуляются, чтобы исключить учёт повторных попаданий. Горизонт прогноза задаётся параметром forecast_horizon_minutes в конфигурации (по умолчанию 30 минут).

Сформированные прогнозы сохраняются в таблицу prediction_log. По истечении горизонта выполняется обновление фактических исходов: для каждого прогноза определяется, произошёл ли переход в критическое состояние в течение заданного интервала.

Оценка качества и достоверности

Для оценки качества прогнозов предусмотрен комплекс метрик:

• Brier score – среднеквадратичная ошибка вероятностных прогнозов.

• Log-loss – логистическая потеря, чувствительная к уверенным неправильным прогнозам.

• MAE – средняя абсолютная ошибка.

• ECE (Expected Calibration Error) – средневзвешенное отклонение между предсказанными вероятностями и наблюдаемыми частотами.

• MCE (Maximum Calibration Error) – максимальное отклонение калибровки.

• ROC-AUC – площадь под ROC-кривой, характеризующая дискриминационную способность модели.

Достоверность прогнозов оценивается рейтингом от 0 до 5 на основе трёх факторов: общего числа переходов, стабильности вероятностей и покрытия частых состояний.

Профилирование нагрузки (версия 14)

Начиная с версии 14, система дополнена модулем профилирования нагрузки.

Этот модуль позволяет:

• Сохранять оперативные (за последние 60 минут), суточные и недельные профили производительности.

• Строить эталонные профили на основе исторических данных с исключением инцидентных окон.

• Обнаруживать аномалии путём сравнения текущих профилей с эталонными.

• Анализировать связь между отклонениями профилей и возникновением инцидентов.

Функция compare_profiles выполняет сравнение текущего профиля с эталонным, вычисляя JS-дивергенцию гистограмм состояний и формируя статус (NORMAL, WARNING, CRITICAL).

Результаты сохраняются в журнал profile_comparison_log, что позволяет проводить ретроспективный анализ.

Историческое обучение

Для первоначального построения модели предусмотрена процедура mchain_initial_train_from_history, которая обучает цепь Маркова на исторических данных, имитируя пошаговое обучение.

Это позволяет развернуть систему на основе уже накопленных метрик без необходимости ждать накопления данных в реальном времени.

Заключение

Представленная реализация цепи Маркова представляет собой законченную систему прогнозирования риска инцидентов производительности, интегрированную в экосистему pg_expecto.

Ключевые преимущества системы:

• работа в реальном времени с низкой задержкой;

• адаптация к изменению характера нагрузки благодаря механизму забывания;

• гибкая настройка горизонта прогноза и параметров обучения;

• встроенные механизмы оценки качества и достоверности;

• расширяемая архитектура, дополненная модулем профилирования нагрузки.

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

Дальнейшее развитие проекта направлено на углубление аналитических возможностей и повышение точности прогнозов.

Аннотация.

В статье представлены результаты экспериментальной верификации гибридного метода раннего обнаружения предотказных состояний СУБД PostgreSQL, сочетающего марковское профилирование нагрузок и оценку статистической дивергенции распределений (JS-дивергенцию). На основе суточного массива реальных данных (439 прогнозов, 13 подтверждённых инцидентов) показано, что предложенный подход обеспечивает 100%-ное обнаружение инцидентов с временем упреждения от 15 до 140 минут, при этом статус CRITICAL предшествует каждому событию (медианное упреждение — 45 мин). Установлено, что профильная структурная диагностика фиксирует аномалии в тех случаях, когда классические марковские прогнозы риска ещё не дают значимых отклонений. Новизна работы заключается в интеграции двух независимых каналов оценки – вероятностного и структурного – что позволяет различать постепенную деградацию и резкие сдвиги в поведении системы. Практическая ценность метода подтверждается высокими показателями точности (Accuracy = 0.868, Precision = 0.899, Recall = 0.886) и стабильностью сигнала, что рекомендует его в качестве дополнения к существующим системам мониторинга.

Ключевые слова: прогнозирование инцидентов, СУБД PostgreSQL, профили производительности, цепи Маркова, JS-дивергенция, раннее предупреждение, структурная диагностика.

Введение

Современные высоконагруженные информационные системы предъявляют жёсткие требования к доступности и отказоустойчивости СУБД. Традиционные системы мониторинга, ориентированные на пороговые значения метрик (загрузка CPU, количество активных сессий, время отклика), часто срабатывают уже на стадии развивающегося инцидента, когда время на упреждающие действия минимально. Альтернативный подход заключается в анализе профилей производительности – распределений состояний системы во времени, которые могут изменяться задолго до явных проявлений деградации.

В настоящей работе исследуется метод сравнения текущего профиля нагрузки с эталонным (безинцидентным) профилем с помощью метрики Дженсена – Шеннона (JS-дивергенции). Метод дополняется аппаратом цепей Маркова для вероятностной оценки риска перехода в критическое состояние. Цель работы – экспериментально подтвердить прогностическую ценность такого комбинированного подхода, оценить временные характеристики упреждения и устойчивость сигнала на реальных данных суточного мониторинга.

1. Методология и постановка эксперимента

1.1. Формирование эталонного профиля

За эталон принимался интервал длительностью 60 минут, предшествующий всем зафиксированным инцидентам и характеризующийся штатной работой СУБД. Для каждой минуты в этом окне строилась гистограмма состояний системы (на основе агрегированных показателей: число транзакций, время ожидания блокировок, использование буферного кэша, интенсивность контрольных точек и др.). Эталонная гистограмма фиксировалась как нормальное распределение состояний.

1.2. Текущий анализ и вычисление JS-дивергенции

Каждую минуту формировалось скользящее окно той же длины (60 мин), для которого строилась аналогичная гистограмма. Рассчитывалась JS-дивергенция между эталонным и текущим распределениями:

1.3. Классификация статусов

На основе значений JS-дивергенции и Z-оценок для вспомогательных метрик присваивался один из статусов:

• NORMAL – JS < 0.05 (небольшие флуктуации);

• WARNING – 0.05 ≤ JS < 0.10–0.20 (умеренное отклонение);

• CRITICAL – JS ≥ 0.10–0.20 (значительное отклонение);

• INCIDENT – период самого инцидента или восстановления после него (определялся по данным журнала инцидентов).

Период эксперимента – 24 часа (10 июля 2026 г.), всего зафиксировано 13 инцидентов различной длительности (от 9 до 91 минуты). В анализ включены также данные из таблиц prediction_log (прогнозы риска на основе цепи Маркова) и profile_comparison_log (результаты сравнения профилей), что позволило сопоставить два канала оценки.

2. Результаты эксперимента

2.1. Обнаружение и временное упреждение

Все 13 инцидентов были предварены статусом WARNING или CRITICAL (100% чувствительность). Среднее время от первого WARNING до начала инцидента составило ≈ 45 минут, от CRITICAL до инцидента – ≈ 35 минут. Максимальное упреждение зафиксировано для инцидента в 07:51 (WARNING за 142 минуты, CRITICAL – за 115 минут), минимальное – для инцидента в 13:40 (19 минут от WARNING, 4 минуты от CRITICAL). В табл. 1 приведены обобщённые показатели.

Таблица 1. Сводные показатели прогностической эффективности.

2.2. Динамика JS-дивергенции и статусов

На всех эпизодах наблюдался устойчивый рост JS-дивергенции за 1–2 часа до инцидента.

Границы соответствия:

• JS 0.00–0.05 → NORMAL (до инцидента > 60 мин);

• JS 0.05–0.10 → WARNING (30–60 мин);

• JS 0.10–0.20 → WARNING (15–30 мин);

• JS > 0.20 → CRITICAL (< 15 мин).

После завершения инцидента статус INCIDENT сохранялся на 60 минут (период восстановления), что объясняется инерционностью скользящего окна.

2.3. Сопоставление с прогнозами риска цепи Маркова

В ряде случаев (например, в 13:36) сравнение профилей присваивало статус CRITICAL (JS ≈ 0.118), тогда как марковский прогноз риска был равен нулю. Это указывает на то, что профильный метод фиксирует структурные изменения в распределении состояний, которые не отражаются в матрице переходов (вероятности смены состояний остаются номинальными). Таким образом, два метода дают взаимодополняющую информацию.

2.4. Оценка качества прогнозирования (по данным за 13–14 июля)

Для периода 13–14 июля был проведён количественный анализ прогнозов с известным исходом (горизонт – 10 минут, порог классификации 0.5):

• Accuracy = 0.868;

• Precision = 0.899;

• Recall = 0.886.

Эти показатели подтверждают высокую надёжность гибридной модели: ложные срабатывания редки и кратковременны (единичные эпизоды WARNING без последующего инцидента длительностью несколько минут).

3. Обсуждение результатов

3.1. Новизна подхода

Предложенная методика не является простым применением JS-дивергенции. Её новизна заключается в интеграции двух независимых каналов диагностики:
(1) вероятностного – на основе цепей Маркова, оценивающего риск перехода в критическое состояние;
(2) структурного – на основе сравнения профилей, выявляющего аномальные паттерны распределения состояний, которые не сопровождаются изменением переходных вероятностей.

Такое сочетание позволяет различать постепенную деградацию (нарастание вероятности) и резкие сдвиги (структурные скачки), что принципиально важно для гетерогенных нагрузок.

3.2. Практическая ценность

• Раннее упреждение (от 15 минут до 2 часов) даёт инженерам возможность провести профилактические действия (перезапуск пула соединений, корректировка планов запросов, масштабирование) до начала инцидента.

• Высокая чувствительность (100% обнаружение) исключает пропуск событий.

• Стабильность сигнала – статусы WARNING и CRITICAL удерживаются длительное время, что снижает вероятность ложных тревог и позволяет выстраивать автоматизированные сценарии реагирования.

• Дополнительность к существующим средствам – метод может быть внедрён как надстройка над любым мониторингом, собирающим временные ряды метрик.

3.3. Ограничения и пути их преодоления

• Инерционность периода восстановления – обусловлена фиксированной длиной окна (60 мин). Варьирование длины окна (до 30 мин) или введение адаптивного механизма сброса статуса после снижения JS ниже порога может сократить время ложного INCIDENT.

• Кратковременные ложные предупреждения – требуют введения временнóй фильтрации (например, статус WARNING засчитывается только при удержании более 3–5 минут) и динамических порогов, учитывающих суточную цикличность.

4. Выводы и направления развития

Проведённое экспериментальное исследование подтверждает, что метод сравнения профилей производительности на основе JS-дивергенции, дополненный марковским прогнозированием, является высокоэффективным инструментом раннего обнаружения инцидентов СУБД PostgreSQL. Метод демонстрирует:

• 100% полноту обнаружения;

• упреждение от 15 до 140 минут;

• устойчивую корреляцию между ростом JS-дивергенции и приближением инцидента;

• дополнительную ценность по сравнению с изолированным вероятностным прогнозом.

В качестве ближайших направлений развития предлагаются:

• автоматическая калибровка эталонного окна на основе исторических данных (с учётом сезонности);

• оптимизация длины скользящего окна для снижения инерционности;

• внедрение комбинированного индекса (JS + риск) с адаптивным порогом;

• экспериментальная проверка на более длительных выборках (несколько недель) для оценки устойчивости к изменениям схемы и объёма данных.

Разработанная методика может быть рекомендована к практическому внедрению в составе многофакторных систем раннего предупреждения для промышленных эксплуатационных сред.

Рис.1 Практический результат предварительного оповещения о инциденте производительности продуктивной СУБД PostgreSQL.

Методология сравнения:

Эталонное окно – безинцидентный интервал длительностью 60 минут.

Текущее окно – скользящее окно длительностью 60 минут.

Статусы определяются на основе JS-дивергенции и отклонений Z-оценок:

• NORMAL – JS < 0.05 (или небольшое отклонение)

• WARNING – 0.05 ≤ JS < 0.1–0.2 (умеренное отклонение)

• CRITICAL – JS ≥ 0.1–0.2 (значительное отклонение)

• INCIDENT – система находится внутри инцидента или в периоде восстановления

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

P.S. Конечно , рано еще строить оптимистические планы на будущее .
Нужно проверять, тестировать и анализировать. Но факт , есть факт - есть первые результаты .

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

О применении метода сравнения профилей производительности для прогнозирования инцидентов СУБД 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 часов), чтобы принять меры , вместо того чтобы героически исправлять его последствия.