📋Материал подготовлен нейросетью DeepSeek.
1. Введение
📋Цель проверки — установить, можно ли использовать отклонение профиля производительности, построенного на основе марковской модели, как ранний предиктор наступления инцидента.
ℹ️В отличие от прямого прогнозирования инцидентов, данный подход оценивает, изменилось ли поведение системы относительно эталонного профиля, и если да — с какой вероятностью это изменение приведёт к инциденту в ближайшем будущем.
2. Постановка гипотезы
Нулевая гипотеза (H₀)
Изменение профиля (стационарного распределения, матрицы переходов или профильных метрик) не связано с последующими инцидентами. Отклонения происходят случайно и не несут прогностической ценности.
Альтернативная гипотеза (H₁)
Значимое отклонение профиля от эталонного статистически значимо предшествует инцидентам производительности, что позволяет использовать профильные метрики как ранние индикаторы риска.
Этап 1. Формирование эталонного профиля. Список профильных метрик для формирования эталонного профиля производительности
Ниже представлены метрики, которые могут быть вычислены эффективно с использованием уже существующих агрегированных данных (markov_frequencies, transition_log, performance_history) и стандартных SQL-агрегаций.
Все метрики могут быть рассчитаны для каждого временного среза (например, час дня, день недели) и затем сравнены с эталонными значениями.
1. Гистограмма состояний (вектор долей времени)
2. Средняя корреляция
3. Доля времени в критических состояниях
4. Энтропия распределения состояний
5. Средний угол наклона OS(операционная скорость)
Примечание: Использование среднего значения допустимо, исходные данные сглажены медианным сглаживанием => выбросов нет.
6. Средний угол наклона Wait
Примечание: Использование среднего значения допустимо, исходные данные сглажены медианным сглаживанием => выбросов нет.
7. Количество уникальных состояний
8. Средняя длина перехода
9. Доля петель (self‑loops)
10. Максимальная частота перехода
Дополнительные замечания по вычислениям
- Для метрик 1, 4, 7, 8, 9, 10 достаточно использовать таблицу transition_log или агрегированную markov_frequencies. При работе с большими объёмами данных можно поддерживать материализованные представления для каждого среза.
- Метрики 2, 5, 6 требуют обращения к performance_history (или к данным, из которых вычисляются корреляция и углы). Их также можно агрегировать заранее.
- Метрика 3 требует наличия актуального списка критических состояний (таблица critical_states), который может меняться со временем. Рекомендуется фиксировать версию списка при построении эталона.
Хранение эталонных профилей
Для каждого временного среза (например, (hour, day)) следует хранить:
- Средние значения каждой метрики (μ).
- Стандартные отклонения (σ) или доверительные интервалы (квантили).
- Количество наблюдений, использованных для оценки.
Это позволит в реальном времени вычислять отклонение текущих значений от эталона с помощью Z‑оценки или расстояния Махаланобиса.
Преимущества данного набора метрик
- ☑️Минимальная нагрузка на СУБД – все вычисления выполняются с помощью простых агрегаций, без сложных матричных операций или итеративных алгоритмов.
- ☑️Интерпретируемость – каждая метрика имеет чёткий физический смысл и может быть объяснена администратору системы.
- ☑️Масштабируемость – при добавлении новых срезов (например, по дням недели) достаточно пересчитать агрегаты; нет необходимости перестраивать модель заново.
- ☑️Гибкость – набор метрик может быть дополнен или сокращён в зависимости от специфики системы без изменения архитектуры.
Заключение
ℹ️Предложенный набор из 10 профильных метрик полностью удовлетворяет требованию простоты расчёта и низкой нагрузки на СУБД. Они охватывают как статистические свойства распределения состояний, так и динамические характеристики переходов и трендов. Эти метрики могут быть использованы для построения эталонного профиля и последующего обнаружения отклонений, предшествующих инцидентам, что позволяет проверить гипотезу о прогностической ценности профиля.
Уточнение периодичности расчёта профильных метрик
Периодичность расчёта зависит от цели использования (оперативное обнаружение аномалий, долгосрочный мониторинг, формирование эталона) и допустимой нагрузки на СУБД. Рекомендуется трёхуровневая стратегия, где каждый уровень имеет свою частоту и глубину окна.
1. Оперативный профиль (для раннего обнаружения отклонений)
Временное окно: последние 60 минут.
Частота пересчёта: каждые 5 минут (или каждую минуту, если позволяет производительность).
Назначение: Быстрое выявление резких изменений в поведении системы, которые могут предшествовать инциденту.
Метрики, которые имеют смысл:
- Гистограмма состояний (сглаженная по времени).
- Средняя корреляция.
- Доля времени в критических состояниях.
- Энтропия.
- Средняя длина перехода.
- Доля петель.
- Максимальная частота перехода (топ-1 переход).
Способ расчёта: Использовать transition_log за последние 60 минут, агрегируя по состояниям. Для снижения нагрузки можно поддерживать материализованное представление, обновляемое по расписанию (например, каждые 5 минут).
Пример использования: Если текущие значения отклоняются от эталона более чем на 2 стандартных отклонения, генерировать предупреждение.
2. Суточный профиль (для анализа дневных паттернов)
Временное окно: последние 24 часа (или текущие сутки).
Частота пересчёта: каждый час.
Назначение: Отслеживание суточных колебаний, сезонных изменений и долгосрочных трендов.
Метрики: Полный набор (все 10 метрик из предыдущего списка).
Способ расчёта: Агрегировать transition_log за последние 24 часа. Можно использовать инкрементальный подход (обновлять профиль, добавляя данные за последний час и удаляя данные за час, вышедший из окна).
Пример использования: Сравнение текущего суточного профиля с эталонным профилем для данного дня недели и часа. Отклонения могут указывать на изменение нагрузки или деградацию.
3. Недельный профиль (для долгосрочного мониторинга и обновления эталона)
Временное окно: последние 7 дней (или скользящая неделя).
Частота пересчёта: раз в день (например, в 00:00 UTC).
Назначение: Оценка общей стабильности системы, выявление медленных дрейфов, обновление эталонных профилей.
Метрики: Полный набор.
Способ расчёта: Агрегировать transition_log за последние 7 дней. Поскольку объём данных велик, расчёт можно выполнять в фоновом режиме (например, ночью).
Пример использования: Если недельный профиль значимо отличается от эталонного (построенного на 30-дневной норме), это сигнал о возможной деградации производительности.
4. Эталонный профиль (норма)
Временной период: исторический отрезок без инцидентов (или с исключёнными инцидентными окнами) длительностью не менее 30 дней.
Частота пересчёта: раз в месяц (или вручную при изменении конфигурации системы).
Назначение: База для сравнения при обнаружении аномалий.
Способ расчёта: Однократный расчёт на основе отфильтрованных данных. Хранить средние значения и стандартные отклонения для каждой метрики по каждому временному срезу (час дня × день недели).
Особенности: При появлении новых инцидентов эталон можно обновлять, исключая из выборки последние инцидентные периоды (скользящее обновление).
Дополнительные рекомендации по нагрузке
- Кэширование: Для оперативного профиля (60 минут) рекомендуется хранить промежуточные агрегаты (например, сумму и сумму квадратов) для быстрого пересчёта при добавлении новых минут.
- Материализованные представления: Создать материализованное представление для суточного и недельного профилей, обновляемое по расписанию.
- Параллелизация: Расчёт различных срезов (по часам, дням недели) можно выполнять параллельно.
- Инкрементальные обновления: Вместо полного пересчёта каждого окна можно использовать технику «скользящего окна»: добавлять новые данные и удалять устаревшие, пересчитывая лишь затронутые агрегаты.
Сводная информация по уровням профиля
📋Оперативный профиль
- Окно: 60 минут
- Частота: каждые 5 минут
- Метрики: гистограмма, средняя корреляция, доля критических, энтропия, средняя длина перехода, доля петель, топ-переход
- Назначение: раннее обнаружение аномалий
Суточный профиль
- Окно: 24 часа
- Частота: каждый час
- Метрики: все 10
- Назначение: анализ суточных паттернов
Недельный профиль
- Окно: 7 дней
- Частота: раз в день
- Метрики: все 10
- Назначение: долгосрочный мониторинг
Эталонный профиль
- Окно: ≥30 дней (норма)
- Частота: раз в месяц (или реже)
- Метрики: все 10 (средние и сигмы)
- Назначение: база для сравнения
ℹ️Такой подход обеспечивает баланс между оперативностью и нагрузкой на СУБД, позволяя эффективно использовать цепь Маркова для профилирования производительности.