Серия «СУБД PostgreSQL»

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

Практическое руководство по развёртыванию тестового стенда PG_EXPECTO + Markov Chain: настройка нагрузочного тестирования через param.conf, автоматический запуск test.sh по cron с пуассоновским распределением нагрузки и целевым количеством инцидентов в сутки.

1. Настройка нагрузочного тестирования

cd /postgres/pg_expecto/sh/load_test
vi param.conf

Пример заполнения файла настройки нагрузочного тестирования

# НАСТРОЙКИ НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ
# Начальная нагрузка
start_load = 5
# Максимальная нагрузка
finish_load = 40
# Тестовая БД
testdb = default
# Тип синтетической нагрузки
#load_mode = olap
load_mode = oltp
# БЕСКОНЕЧНЫЙ ТЕСТ.
# ДЛЯ ОСТАНОВКИ
# /postgres/pg_expecto/sh/load_test/load_test_stop.sh
period_hours = -1
average_load = 20
# Веса сценариев по умолчанию
scenario1 = 0.7
scenario2 = 0.2
scenario3 = 0.1
# Инициализировать тестовую БД
init_test_db = on
# Размер тестовой БД
#scale = 20
#~10GB
scale = 685

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

Скрипт предназначен для автоматического управления нагрузочным тестированием.
Он проверяет количество инцидентов в БД за текущие сутки и в зависимости от целевого значения запускает или останавливает нагрузочный тест.

Для запуска процесса нагрузочного тестирования с Пуассоновским распределением нагрузки и заданным количеством инцидентов в сутки(в примере = 4) - добавить в расписание cron:

0 * * * * /postgres/pg_expecto/sh/load_test/test.sh 4 >> /postgres/pg_expecto/sh/load_test/test.log 2>&1

Изменение операционной скорости и ожиданий в ходе нагрузочного тестирования

Операционная скорость СУБД

Ожидания СУБД

Распределение инцидентов по часам (0-23):

2: **

3: **

4: ****

5: *** 

6: ** 

7: * 

8: ****

9: ** 

11: * 

14: * 

17: **

Распределение инцидентов по дням недели (0-6, 0=Вс):

День 0: ******

День 1: *** 

День 2: *** 

День 3: ** 

День 4: **** 

День 5: *** 

День 6: ***

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

Разработка и оценка гибридной методологии раннего предупреждения на основе марковских переходов, JS-дивергенции профилей нагрузки и взвешенного сигнала SICPP: месячное пилотное исследование с ROC-AUC 0,9593 и покрытием 96,4 % несерийных инцидентов

Аннотация

Рассматривается практическое применение марковской модели переходов между состояниями производительности СУБД для прогнозирования инцидентов и раннего предупреждения деградации. Архитектура решения включает профилирование нагрузки, сравнение гистограмм состояний на основе JS-дивергенции, динамический список критических состояний, прогноз риска на заданный горизонт и интегральный сигнал SICPP. По результатам отчётного периода с 16 сентября по 16 октября 2026 г. получены 28 несерийных инцидентов, из которых для 27 (96,4 %) был зафиксирован активный сигнал. ROC-AUC составил 0,9593, Brier score — 0,056062. Показано, что совместное использование JS-дивергенции и предсказанного риска в режиме WEIGHTED обеспечивает высокую полноту обнаружения при умеренной частоте ложных срабатываний. Обсуждаются ограничения, связанные с latch-эффектом SICPP, калибровкой в средних диапазонах риска и малой выборкой.

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

1. Введение

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

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

В данной работе исследуется гибридная схема, объединяющая:

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

• профилирование нагрузки и сравнение эталонного и текущего профилей;

• JS-дивергенцию гистограмм состояний;

• динамический список критических состояний;

• интегральный сигнал SICPP, учитывающий как риск, так и расхождение профилей.

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

2. Материалы и методы

2.1. Архитектура данных

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

• Журнал переходов. Таблица transition_log хранит последовательность переходов между состояниями с временными метками.

• Частоты и вероятности. Таблицы markov_frequencies и markov_probabilities содержат накопленные частоты и условные вероятности переходов.

• Поглощающая матрица. Таблица markov_absorbing используется для многошагового прогноза риска, при этом критические состояния рассматриваются как поглощающие.

• Справочник состояний. Таблица state_descriptions содержит 189 состояний, образованных комбинацией округлённой корреляции, тренда операционной скорости и тренда ожиданий.

• Критические состояния. Таблица critical_states формируется динамически на основе эмпирической частоты инцидентов после перехода в состояние.

• Журнал прогнозов. Таблица prediction_log хранит предсказанный риск, состояние на момент прогноза и фактический исход.

• Профили нагрузки. Таблицы profile_aggregated, profile_comparison_log, pre_incident_profiles обеспечивают сравнение текущего и эталонного профилей.

• История SICPP. Таблицы sicpp_history и sicpp_current_state фиксируют изменения интегрального сигнала.

2.2. Профилирование нагрузки и JS-дивергенция

Профиль нагрузки описывается гистограммой состояний, а также рядом метрик: средней корреляцией, долей критических состояний, энтропией, долей петель, средними углами трендов и др. Для снижения разреженности гистограмм применяется сглаживание Лапласа с параметром α = 0,5 по всем 189 состояниям. Это позволяет получать содержательные значения JS-дивергенции в диапазоне 0,05–0,30 вместо вырожденных значений, близких к теоретическому максимуму.

Сравнение профилей выполняется между текущим окном и эталонным окном, свободным от инцидентов. Если JS-дивергенция превышает порог, статус сравнения повышается до WARNING или CRITICAL. Дополнительно учитываются максимальный предсказанный риск и устойчивость: например, если 3 из 5 последних сравнений имели статус CRITICAL или WARNING, формируется расширенный прединцидентный флаг.

2.3. Цепь Маркова и прогноз риска

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

Ключевые особенности реализации:

• горизонт прогноза задаётся в markov_config.forecast_horizon_minutes;

• критические состояния определяются не только экспертно, но и по эмпирическому риску;

• адаптивное забывание уменьшает старые частоты с коэффициентом, зависящим от времени с последнего инцидента;

• для устойчивости вычислений используется тип DOUBLE PRECISION, поскольку ранее применение REAL приводило к антипереполнению при малых вероятностях и искажению метрик.

2.4. SICPP как интегральный сигнал

SICPP (Signal Indicating a Change in the Performance Profile) объединяет две компоненты:

• нормированную JS-дивергенцию;

• нормированный предсказанный риск.

В режиме WEIGHTED сила сигнала рассчитывается как

В версии SICPP 1.1.0 изменена семантика signal_active: сигнал считается активным, если в окне [pts−window,pts−1][pts−window,pts−1] присутствовал хотя бы один непрерывный пробег длительностью не менее min_signal_duration. Это соответствует логике функции calculate_signal и приводит к latch-эффекту: сигнал остаётся активным в течение окна после завершения подходящего пробега.

2.5. Оценка качества

Качество прогнозирования оценивается по нескольким направлениям:

• ROC-AUC — дискриминационная способность модели по prediction_log.actual_outcome;

• Brier score — среднеквадратичная ошибка вероятностного прогноза;

• калибровочная кривая — сопоставление предсказанного риска и фактической частоты инцидентов;

• покрытие инцидентов сигналом — доля несерийных инцидентов, перед которыми SICPP был активен;

• среднее время от сигнала до инцидента — оценка запаса времени для упреждающих действий.

3. Результаты

3.1. Общая характеристика отчётного периода

Отчёт сформирован за период с 16 сентября 2026 г. 13:53 по 16 октября 2026 г. 13:53. Источник сигнала — sicpp_history. В периоде зафиксирована 81 запись, первая — 4 октября 2026 г. 13:33.

Параметры конфигурации:

• окно анализа — 60 минут;

• порог JS-дивергенции — 0,15;

• порог риска — 0,85;

• режим сигнала — WEIGHTED;

• минимальная длительность сигнала — 3 минуты;

• вес JS — 0,7;

• вес риска — 0,3;

• автоподбор порогов — выключен;

• период калибровки — 7 дней;

• расширенный отчёт — включён.

3.2. Покрытие инцидентов сигналом

Всего в отчёте учтено 28 инцидентов, не являющихся продолжением серий. Исключено 11 серийных инцидентов, у которых последний статус перед инцидентом был INCIDENT.

Основные результаты:

• с сигналом SICPP — 27 инцидентов;

• доля инцидентов с сигналом — 96,4 %;

• без сигнала — 1 инцидент (ID 88);

• среднее время от сигнала до инцидента — 382,8 минуты;

• средняя JS-дивергенция — 0,1180;

• средний риск — 0,7621.

Распределение последних статусов перед инцидентами:

• CRITICAL — 18;

• WARNING — 8;

• NORMAL — 0;

• INCIDENT — 0;

• нет данных — 0.

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

3.3. Метрики качества прогноза

Качество прогнозирования на основе prediction_log.actual_outcome характеризуется следующими значениями:

• ROC-AUC — 0,9593;

• Brier score — 0,056062.

Столь высокое значение ROC-AUC указывает на хорошую дискриминационную способность модели: она уверенно разделяет прогнозы с последующим инцидентом и без него.

Низкий Brier score свидетельствует о том, что вероятностные оценки в целом близки к фактическим исходам.

3.4. Калибровочная кривая

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

• Диапазон [0,0–0,1]: предсказано 0,000, фактически 1,000, n = 7.

• Диапазон [0,1–0,2]: предсказано 0,177, фактически 0,161, n = 1642.

• Диапазон [0,2–0,3]: предсказано 0,256, фактически 0,184, n = 3616.

• Диапазон [0,5–0,6]: предсказано 0,575, фактически 1,000, n = 117.

• Диапазон [0,6–0,7]: предсказано 0,681, фактически 1,000, n = 516.

• Диапазон [0,7–0,8]: предсказано 0,782, фактически 1,000, n = 418.

• Диапазон [0,8–0,9]: предсказано 0,874, фактически 1,000, n = 414.

• Диапазон [0,9–1,0]: предсказано 0,981, фактически 0,984, n = 3833.

• Диапазон [1,0–1,1]: предсказано 1,000, фактически 0,998, n = 6699.

Наиболее надёжными выглядят диапазоны высокого риска: при предсказании около 0,98–1,00 фактическая частота близка к 0,98–1,00. В то же время в средних диапазонах 0,5–0,9 наблюдается смещение: фактическая частота оказывается выше предсказанной. Это может быть связано как с малой выборкой в отдельных бинах, так и с переоценкой модели в переходных режимах.

3.5. Временные распределения

Распределение инцидентов по часам суток показывает выраженную неравномерность.

• Наибольшая концентрация наблюдается в 4 часа (5 инцидентов).

• Далее следуют 3, 5, 8, 9 и 17 часов (по 3–4 инцидента).

• Единичные инциденты зафиксированы в 2, 6, 7, 10, 11, 14 и 15 часов.

• В остальные часы инцидентов в отчётном периоде не было.

Распределение по дням недели:

• воскресенье — 6 инцидентов;

• пятница — 6 инцидентов;

• понедельник — 3;

• вторник — 3;

• среда — 2;

• четверг — 4;

• суббота — 4.

3.6. Примеры инцидентов

В отчёте приведены детали по каждому инциденту. Наиболее показательные случаи:

• ID 70: сигнал активен, время до инцидента — 888 минут, длительность сигнала — 3 минуты, средний риск — 0,8440, JS — 0,0530.

• ID 77: сигнал активен, время до инцидента — 133 минуты, длительность сигнала — 60 минут, средний риск — 0,9989, JS — 0,1983.

• ID 92: сигнал активен, время до инцидента — 959 минут, длительность сигнала — 37 минут, приоритет — 3, средний риск — 0,7055.

• ID 94: сигнал активен, время до инцидента — 8 минут, длительность сигнала — 3 минуты, средний риск — 0,9666, JS — 0,1488.

• ID 97: сигнал активен, время до инцидента — 1041 минута, длительность сигнала — 60 минут, средний риск — 0,2298, JS — 0,2280.

• ID 88: сигнал отсутствовал, последний статус — WARNING, тренд — РОСТ, риск — 0,8373, JS — 0,1405.

Эти примеры показывают, что сигнал может возникать как за несколько минут, так и за несколько часов до инцидента. В части случаев срабатывание происходило преимущественно за счёт JS-дивергенции, даже если средний риск был ниже порога 0,85. Это подтверждает полезность взвешенного режима.

4. Обсуждение

Полученные результаты позволяют сделать несколько содержательных выводов.

• Высокая полнота обнаружения. Сигнал SICPP был активен перед 27 из 28 несерийных инцидентов. Это свидетельствует о том, что совместное использование профильного расхождения и марковского риска позволяет покрывать практически все значимые события.

• Хорошее качество вероятностного прогноза. ROC-AUC 0,9593 и Brier score 0,056062 находятся на уровне, характерном для хорошо настроенных моделей раннего предупреждения. Особенно важно, что низкий Brier score достигается при наличии большого числа прогнозов в области высокого риска.

• Роль JS-дивергенции. Средняя JS-дивергенция перед инцидентами составила 0,1180, что ниже порога 0,15. Однако в режиме WEIGHTED даже умеренное превышение по одной из компонент может привести к активации сигнала. Это расширяет чувствительность системы.

• Роль риска. Средний риск перед инцидентами — 0,7621, что также ниже порога 0,85. Тем не менее в ряде случаев риск достигал 0,99 и выше. Комбинирование с JS-дивергенцией позволяет не пропускать инциденты, где риск ещё не достиг экстремальных значений.

• Latch-эффект SICPP. Поскольку signal_active остаётся истинным в течение окна после завершения подходящего пробега, время от сигнала до инцидента может быть значительным. Это полезно для раннего предупреждения, но требует осторожной интерпретации: сигнал означает, что в предшествующем окне уже наблюдались признаки изменения профиля, а не обязательно непрерывную активность вплоть до инцидента.

• Калибровка в средних диапазонах. В бинах 0,5–0,9 фактическая частота инцидентов оказалась выше предсказанной. Это указывает на потенциальную область улучшения: возможно, требуется дополнительная калибровка или учёт нелинейностей в переходных режимах.

• Малая выборка. Несмотря на 28 несерийных инцидентов, для некоторых бинов калибровочной кривой количество наблюдений мало. Это ограничивает статистическую устойчивость выводов по отдельным диапазонам.

5. Ограничения

Следует отметить ряд ограничений исследования.

• Отчётный период составляет один месяц; для подтверждения устойчивости результатов необходима более длительная валидация.

• SICPP использует latch-семантику, из-за чего время от первого сигнала до инцидента может быть завышено относительно «мгновенной» активации.

• Калибровочная кривая в средних диапазонах риска демонстрирует смещение, что требует дополнительного анализа.

• Часть инцидентов имеет серийный характер; в отчёте они исключаются, однако сам механизм исключения опирается на статус INCIDENT и может требовать уточнения.

• Качество модели зависит от полноты transition_log, prediction_log и sicpp_history; пропуски в данных могут искажать оценки.

6. Заключение

Предложенная архитектура, объединяющая цепь Маркова, профилирование нагрузки, JS-дивергенцию и интегральный сигнал SICPP, показала высокую эффективность на отчётном периоде. Основные результаты:

• 27 из 28 несерийных инцидентов (96,4 %) сопровождались активным сигналом;

• ROC-AUC — 0,9593;

• Brier score — 0,056062;

• среднее время от сигнала до инцидента — 382,8 минуты;

• распределение последних статусов перед инцидентами: CRITICAL — 18, WARNING — 8.

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

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

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

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

Период анализа: 2026-07-19 15:54 – 2026-08-19 12:53

Конфигурация сигнала: режим WEIGHTED (вес JS=0.9, вес риска=0.1), порог JS=0.2, порог риска=0.8, мин. длительность сигнала=3 минуты

Всего инцидентов (уникальных): 338 (исключено 71 серийный, т.е. продолжающих предыдущий)

1. Эффективность обнаружения (Recall)

• ✅Сигнал сработал перед инцидентом в 84% случаев (284 из 338).

• ✅Среднее время упреждения – 58.7 минут (почти час), что даёт достаточный задел для реакции.

• ✅Медианное время до инцидента (по деталям) – также близко к 60 минутам (большинство сигналов возникают ровно за час).

📋Вывод: модель обладает высокой чувствительностью и обеспечивает своевременное предупреждение. Однако 16% инцидентов происходят без сигнала – это потенциальная зона для улучшения.

2. Распределение последних статусов перед инцидентом

CRITICAL: 207 инцидентов (61.2%) – более 60% инцидентов происходят сразу после статуса CRITICAL, что ожидаемо и подтверждает, что критические отклонения часто предшествуют сбоям.

NORMAL: 106 инцидентов (31.4%) : почти треть инцидентов случаются после статуса NORMAL, т.е. система не подавала предупреждений. Это указывает на:

• недостаточную чувствительность порогов (возможно, JS-порог 0.2 или риск-порог 0.8 слишком высоки для некоторых сценариев);

• наличие инцидентов, которые развиваются слишком быстро (менее чем за 3 минуты – минимальная длительность сигнала);

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

INCIDENT: 24 инцидента (7.1%) – это продолжения серий, которые были исключены, но в данном контексте означают, что сразу после инцидента начинается новый.

WARNING: 1 инцидент (0.3%) – единичный случай, статистически незначим.

3. Качество прогнозов риска (по данным prediction_log)

• ROC-AUC = 0.8636 – отличная дискриминационная способность (модель хорошо разделяет инцидентные и безынцидентные окна).

• Brier score = 0.1138 – приемлемое значение (чем меньше, тем лучше; обычно <0.25 считается хорошим).

Калибровочная кривая (риск vs. фактическая частота) в виде списка бинов:

• Бин [0.0–0.1]: предсказано 0.023, фактически 0.052

• Бин [0.1–0.2]: предсказано 0.158, фактически 0.274

• Бин [0.2–0.3]: предсказано 0.277, фактически 0.282

• Бин [0.3–0.4]: предсказано 0.381, фактически 0.416

• Бин [0.4–0.5]: предсказано 0.450, фактически 0.417

• Бин [0.5–0.6]: предсказано 0.580, фактически 0.618

• Бин [0.6–0.7]: предсказано 0.603, фактически 0.562

• Бин [0.7–0.8]: предсказано 0.718, фактически 0.662

• Бин [0.8–0.9]: предсказано 0.884, фактически 0.400

• Бин [1.0–1.1]: предсказано 1.000, фактически 0.600

Наблюдение: систематическая переоценка риска в верхнем диапазоне – для бинов 0.8–0.9 и 1.0–1.1 фактические частоты значительно ниже предсказанных.

📋Рекомендация: скорректировать вероятности с помощью калибровки (например, изотоническая регрессия или Platt scaling) или пересмотреть пороги для высоких рисков, чтобы уменьшить ложные срабатывания.

4. Характеристики профилей перед инцидентами

• ℹ️Средняя JS-дивергенция за час до инцидента = 0.3548 (высокое значение, указывает на значительные изменения в распределении состояний).

• ℹ️Средний предсказанный риск за час до инцидента = 0.1621 (относительно низкий, но в момент сигнала риск часто достигает 1.0 – см. детали).

• ℹ️Тренд риска перед инцидентом: в большинстве случаев РОСТ (что логично), реже – СНИЖЕНИЕ или СТАБИЛЬНО.

📋Вывод: профиль нагрузки перед инцидентами существенно отклоняется от эталона, и риск имеет тенденцию к росту. Это подтверждает правильность выбора JS-дивергенции как ключевого предиктора.

5. Совпадения с пред-инцидентными профилями

• 0 инцидентов (0%) имели совпадение с библиотекой pre_incident_profiles (шаблон ID = NULL).

• ℹ️Это означает, что либо библиотека шаблонов недостаточно полна, либо порог совпадения (0.05 JS) слишком строгий, либо текущие сценарии инцидентов не повторяют ранее зафиксированные.

📋Рекомендация: расширить библиотеку, используя автоматический сбор профилей для всех инцидентов (функция collect_pre_incident_profiles), и поэкспериментировать с более мягким порогом (0.1–0.15) для увеличения числа совпадений.

6. Временное распределение инцидентов

• По часам суток: пики приходятся на 19:00–20:00 (18 инцидентов) и 04:00–05:00 (17 инцидентов). Это может указывать на периоды пиковой нагрузки или выполнения плановых задач (бэкапы, отчёты).

• По дням недели: наибольшее число инцидентов во вторник (около 60), наименьшее – в воскресенье (около 36).

Рекомендация: усилить мониторинг в часы пик и во вторник, возможно, увеличить чувствительность сигнала в эти периоды.

7. Общая оценка и рекомендации

✅Сильные стороны:

• Высокая чувствительность (84% recall) и большое время упреждения (~1 час).

• Отличная дискриминация (ROC-AUC > 0.86).

• Система успешно улавливает большинство инцидентов через изменения профиля нагрузки.

Слабые стороны и точки роста:

1. 16% пропущенных инцидентов – необходимо проанализировать их сценарии и, возможно, снизить порог риска или JS для отдельных типов.

2. 31% инцидентов после статуса NORMAL – это «внезапные» события, которые могут быть связаны с резкими скачками нагрузки. Стоит добавить детектор резких изменений (например, производную JS или риска).

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

4. Отсутствие совпадений с пред-инцидентными профилями – расширить библиотеку и настроить порог совпадения.

5. Временные паттерны – можно внедрить адаптивные пороги, зависящие от времени суток и дня недели.

Приоритетные действия:

• Провести анализ 54 инцидентов без сигнала (16%) – выделить общие признаки и дополнить правила их обнаружения.

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

• Запустить сбор пред-инцидентных профилей для всех новых инцидентов и пересмотреть порог совпадения.

• Настроить автоматическое оповещение при переходе в статус CRITICAL, а также при резком росте JS или риска даже при статусе NORMAL.

📋Итоговый вердикт

ℹ️Система прогнозирования инцидентов демонстрирует высокую эффективность и пригодна для эксплуатации.

Основные метрики (recall, ROC-AUC, время упреждения) находятся на хорошем уровне.

ℹ️Выявленные недостатки носят уточняющий характер и могут быть устранены путём калибровки, расширения библиотеки шаблонов и адаптации порогов к временным паттернам.

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

Начало

Практическое применение методики прогнозирования инцидента производительности СУБД PostgreSQL

Текущий статус эксперимента

Случай-1 : Инцидент

• JS-дивергенция > 0.4

• Прогноз риска > 0.6

Случай-2 : Инцидент

• JS-дивергенция > 0.4

• Прогноз риска > 0.6

Случай-3 : Нет инцидента

• JS-дивергенция > 0.4

• Прогноз риска < 0.6

Случай-4 : Инцидент

• JS-дивергенция > 0.4

• Прогноз риска > 0.6

Гипотеза

• Превышение значения JS-дивергенции выше 0.4 при одновременном максимальном значении Прогноза риска = 1, может служить сигналом о приближении инцидента производительности СУБД

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

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

1. Введение

Настоящий отчёт подготовлен на основе данных системы мониторинга производительности СУБД, построенной на базе цепи Маркова и профилирования нагрузки. Анализ охватывает период с 00:00 13.07.2026 по 00:00 14.07.2026 (сутки). Использованы следующие методы:

• Прогнозирование риска – вычисление вероятности перехода в критическое состояние в течение заданного горизонта (на основе матрицы переходов и списка критических состояний).

• Сравнение профилей – оценка отклонения текущего распределения состояний системы от эталонного безынцидентного профиля с помощью JS-дивергенции (метрика сходства гистограмм).

• Классификация статусов – по значению JS-дивергенции и отклонению средней корреляции выделяются три уровня: NORMAL, WARNING, CRITICAL.

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

2. Общая характеристика прогнозов

За период было сформировано 439 прогнозов с известным исходом (т.е. для каждого известно, наступил ли инцидент в течение прогнозного горизонта). Среднее значение предсказанного риска составило 0.6173, что указывает на достаточно высокий уровень ожидаемой опасности в среднем по всем наблюдениям.

Качество прогнозов оценивалось при пороге классификации 0.5:

• Accuracy (точность) – 0.8679 (высокая)

• Precision (точность положительных прогнозов) – 0.8993 (высокая)

• Recall (полнота) – 0.8860 (высокий)

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

3. Анализ сравнения профилей (статусы)

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

• NORMAL – 45 наблюдений (10.3%)

• WARNING – 95 наблюдений (21.6%)

• CRITICAL – 299 наблюдений (68.1%)

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

Средние значения JS-дивергенции по группам:

• NORMAL: 0.0210 – профиль близок к эталону

• WARNING: 0.1371 – заметные отклонения

• CRITICAL: 0.2913 – сильное расхождение распределения состояний

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

4. Связь с инцидентами

За сутки зафиксировано 19 инцидентов производительности. Анализ показал:

• 100% инцидентов предварялись статусом CRITICAL (ни одного инцидента не произошло после NORMAL или WARNING).

• Временной интервал от момента присвоения статуса CRITICAL до начала инцидента:
  минимум: 0.9 мин
  максимум: 132.0 мин
  среднее: 48.6 мин
  медиана: 45.0 мин

Эти данные подтверждают, что статус CRITICAL является эффективным ранним индикатором надвигающегося инцидента. Среднее время упреждения (~45 минут) значительно превышает типичный горизонт прогноза (в текущей конфигурации – 10 минут), что объясняет, почему не все CRITICAL состояния сразу приводят к инциденту в рамках короткого прогноза. Это также указывает на возможность увеличения горизонта прогноза для более полного охвата событий.

Обращает на себя внимание диспропорция: 299 CRITICAL-состояний при всего 19 инцидентах. Это означает, что большинство CRITICAL-отклонений не заканчиваются инцидентом, по крайней мере, в течение наблюдаемого периода. Вероятно, часть отклонений связана с плановыми изменениями нагрузки, пиковыми, но не аварийными сценариями. Тем не менее, все реальные инциденты были предсказаны, что говорит о высокой чувствительности метода.

5. Оценка трендов

По данным за сутки:

• Тренд JS-дивергенции – СТАБИЛЬНО (нет значимого роста или снижения).

• Тренд среднего риска – СТАБИЛЬНО.

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

6. Выводы

1. Модель прогнозирования демонстрирует высокое качество
   Обоснование: Accuracy = 0.8679, Precision = 0.8993, Recall = 0.8860 – все метрики превышают 0.86, что свидетельствует о хорошей дискриминационной способности и сбалансированности между ложными тревогами и пропусками. Средний предсказанный риск (0.6173) значительно выше случайного (0.5), что говорит о наличии уверенных сигналов.

2. Статус CRITICAL является надёжным предвестником инцидента
   Обоснование: Все 19 зафиксированных инцидентов произошли после присвоения статуса CRITICAL (100% покрытие). Ни один инцидент не случился после NORMAL или WARNING. Медианное время от CRITICAL до инцидента составляет 45 минут, что даёт достаточный запас для реагирования.

3. Доля CRITICAL-состояний чрезмерно высока (68%)
   Обоснование: При 19 инцидентах на 299 CRITICAL-событий соотношение составляет ~1:15. Это означает, что подавляющее большинство CRITICAL-отклонений не приводят к аварийным ситуациям. При этом средняя JS-дивергенция в группе CRITICAL (0.2913) значительно выше порогов, но не является критической (максимальное значение не указано, но если бы оно было близко к 1, то ситуация была бы иной). Следовательно, текущие пороги классификации занижены, что приводит к избыточному числу предупреждений.

4. Временной запас до инцидента достаточен для упреждающих действий
   Обоснование: Разброс времени от CRITICAL до инцидента – от 0.9 до 132 минут, среднее 48.6, медиана 45. Это значительно превышает используемый горизонт прогноза (10 минут). Таким образом, существует возможность увеличить горизонт, чтобы лучше согласовать прогноз с реальным временем развития событий.

5. Отсутствие трендов указывает на стабильность режима работы
   Обоснование: Тренды как JS-дивергенции, так и среднего риска оценены как СТАБИЛЬНО. Это означает, что за сутки не выявлено направленного дрейфа метрик – система не деградирует и не восстанавливается, а находится в квазистационарном состоянии с повторяющимися эпизодами отклонений. Отсутствие тренда также подтверждает, что выявленные CRITICAL-отклонения не являются следствием нарастающей проблемы, а скорее отражают циклические или стохастические колебания нагрузки.

Дата составления: 14.07.2026
Ответственный: Группа анализа производительности