The post has been translated automatically. Original language: Russian
Original on the main technical blog : Markov chain for DBA: evolution, filtration and the path to commercial operation (corrections and additions are possible)
Version 12.1 is an important evolutionary step, but its accuracy, stability and suitability for real—world systems have yet to be proven through a series of large-scale studies: from long-term validation and control of distribution drift to integration into the monitoring landscape and ensuring reliability in emergency situations.
Additional materials on the application of the Markov chain in the pg_expecto project
Predicting emergencies in complex dynamic systems such as the PostgreSQL database management system faces the fundamental problem of the unsteady distribution of observed parameters and the multiplicity of incident scenarios.
This paper presents the evolution of the Markov forecasting model, which has gone from a static absorbing matrix with rigidly defined accident criteria (version 10.1.6) to a self-adjusting iterative mechanism with a dynamically updated list of critical states based on empirical risk (version 11.3), and finally to the current version 12.1, where the key innovation was the filtering of transitions in the assessment stability — exclusion of critical states and rare events with a number of transitions less than the threshold value.
This evolution reflects the gradual realization that the reliability of a forecast is determined not only by the accuracy of probabilistic estimates, but also by the resilience of the model itself to outliers and sparse data.
The article consistently analyzes architectural changes, compares approaches to determining accidents, calculating horizons and parameters of forgetting, and formulates a set of open problems that need to be solved for the transition to industrial operation.
The first implementation was based on the assumption of stationarity and used fixed emergency criteria. The model worked with 189 states, which were combinations of three parameters — correlation, OS trend, and expectation trend. Only one strict condition was considered an emergency: a negative correlation with a falling trend in operating systems and a growing trend in expectations.
The forecast was built through an absorbing matrix, recalculated with each update of probabilities. The horizons were fixed — 1, 15, 30 and 60 minutes. Reliability was assessed on a five-point scale based on the amount of data and the stability of probabilities. It was a working solution, but it did not take into account that real incidents may manifest themselves differently, and the system parameters change over time.
The methodology used in version 11 is fundamentally different. Instead of a strict condition, the developers introduced the critical_states table, which is automatically updated with the refresh_critical_states function based on the empirical risk from the incident table. Now emergency conditions are not determined once and for all, but are extracted from the history of observations.
At the same time, the forecasting mechanism itself has changed: The absorbing matrix has given way to an iterative calculation with zeroing out the probabilities of critical states at each step. The horizon has become unified and is set in the configuration (by default, 30 minutes). New reports have appeared, including mchain_quality_report, and reliability has been penalized for instability.
It was a step towards a self-learning system, but there was still a problem.: The stability of the model was assessed for all transitions, including rare and emergency ones, which could distort the real picture.
The latest release does not introduce drastic architectural changes, but it significantly clarifies how we measure stability.
The main innovation is filtering when calculating the maximum change in transition probabilities (max_prob_change).
Excluded from the analysis:
- transitions to critical states (those listed in critical_states);
- states for which less than 200 transitions were recorded during the analyzed period.
This allows you to cut off the noise.: rare events and emergency peaks cease to affect the stability assessment, making it more representative. In addition, the default forgetting parameters have been adjusted — the interval has been reduced from 180 to 60 minutes, and the basic alpha coefficient has been reduced from 0.1 to 0.07. This setting ensures smoother adaptation to new data, reducing sudden spikes.
Filtering is implemented in all key functions: mchain_check_sufficiency, mchain_forecast_reliability, mchain_reliability_report, evaluate_forgetting_params, and report_stability_trend. Now each reliability report takes into account only statistically significant and non-critical transitions.
If we summarize the differences, we can identify several axes of development.
- Version 10: a hard logical condition embedded in the code.
- Versions 11 and 12: a dynamic list of critical_states, updated based on incident data.
- Version 10: An absorbing matrix that can be rebuilt with each update.
- Versions 11 and 12: iterative zeroing of critical state probabilities without using an absorbing matrix.
- Version 10: four fixed horizons (1, 15, 30, 60 minutes).
- Versions 11 and 12: a single horizon set in the configuration (30 minutes by default).
- Versions 10 and 11: all transitions were taken into account, without exceptions.
- Version 12: Critical state transitions and states with fewer than 200 transitions are excluded.
- Versions 10 and 11: interval_minute=180, base_alpha=0.1.
- Version 12: interval_minute=60, base_alpha=0.07.
Version 12.1 is not a revolution, but an evolutionary refinement that makes the model more resilient to outliers and rare events.
Thanks to filtering, stability assessment has become more objective, and forecasts are more reliable in real-world operating conditions.
However, it is too early to talk about the industrial implementation of the tool: a lot of additional research and testing is required to implement the technique on a productive load.
Among the key areas that need to be worked out are the following.
- Validation based on long-term historical data. The current experiments were conducted on limited samples. To confirm the stability of the model, it is necessary to test it on multi-month PostgreSQL performance archives with various load patterns: seasonal peaks, data migrations, database version updates, and configuration changes. Only such validation will allow us to assess how accurate the model remains when operating conditions change.
- Adaptation to non-stationarity. The performance of real systems changes over time — data volumes grow, queries evolve, and hardware is updated. The first-order Markov chain, assuming stationary transient probabilities, can fail under such conditions. Research is needed on how often the model needs to be retrained, what mechanisms for detecting distribution drift should be implemented, and how to automatically rebuild the state space when the nature of the load changes.
- The problem of sparsity of data. In version 12.1, a threshold of 200 transitions has already been introduced to include the state in the stability calculation. However, on productive systems, many conditions may remain rare, especially during the initial observation period. This raises the question of developing smoothing methods (for example, Bayesian a priori regularization) or aggregating similar states in order to increase the statistical significance of estimates without losing sensitivity to anomalies.
- Computational scalability. As the number of observed parameters increases, the state space can grow rapidly. The current implementation uses 189 states, a combination of three parameters. On a productive system, additional metrics may need to be taken into account (number of active sessions, buffer cache size, checkpoint intensity, etc.), which will lead to exponential growth in the number of states. Research is required on dimensionality reduction methods and efficient data structures for storing and updating the transition matrix in real time.
- Calibration of hyperparameters. In version 12.1, the forgetting parameters have been adjusted: interval_minute has been reduced from 180 to 60, and base_alpha — from 0.1 to 0.07. However, the optimal values of these parameters may significantly depend on the specific workload: highly dynamic systems require faster forgetting, while stable systems require longer memory. Systematic research is needed on the automatic selection of hyperparameters, possibly using optimization methods that are adaptive to current conditions.
- Assessment of the quality of forecasts based on productive workload. In laboratory conditions, the model shows encouraging results. However, on real systems, the price of false positives and false negatives is completely different. A false warning can distract the administrator from really important tasks, and skipping an incident can lead to downtime. It is necessary to develop quality metrics that take into account the asymmetry of losses, as well as calibrate response thresholds for specific SLAs and business priorities.
- Integration with existing monitoring systems. Industrial implementation requires seamless integration with common surveillance stacks (Prometheus, Zabbix, Grafana, etc.). This means not only technical compatibility across protocols and data formats, but also alignment of data models: the metrics used by the Markov chain must match those already collected in a productive environment, without the need to refine collection agents.
- Interpretability for engineers. Markov chains provide a probabilistic forecast, but database administrators need not only numbers, but also clear explanations.: why is the model expecting an incident, exactly which transitions between states led to this conclusion, and which metrics should be paid attention to first. More research is needed in the field of explicable artificial intelligence (XAI) in relation to Markov models.
- Comparative studies with alternative approaches. To date, there has been no systematic comparison of the Markov approach with other forecasting methods such as recurrent neural networks, gradient boosting on time series, hidden Markov models or Bayesian structural time series. Without such a benchmark on representative datasets, it is difficult to argue that the Markov chain is the optimal choice, and not just a convenient and interpretable alternative.
- Fault tolerance testing. In a productive environment, the model should work correctly in case of data collection failures, temporary unavailability of the metric storage, delay spikes, and other infrastructure-level anomalies. Stress tests modeling various degradation scenarios of the forecasting mechanism itself are needed to ensure that the failure of the model does not worsen the situation in the system.
Thus, the path to industrial implementation lies through a series of large-scale research and engineering works.: from big data validation to integration into the existing monitoring landscape and ensuring reliability in emergency situations.
The project is open for collaboration, and each of these challenges can become a separate topic for joint development.
The source code is still open and available in the repository. https://github.com/pg-expecto/markov_chain — anyone can study the details of the implementation and contribute to the development of the project.
The analysis of the three versions of the Markov predictive tool demonstrates a consistent improvement in its representativeness and robustness due to the abandonment of static assumptions, the introduction of an empirically updated list of critical conditions, and, in particular, the introduction of filtering of statistically insignificant and emergency transitions in the assessment of stability. Adjusted forgetting parameters (60 minutes interval, base coefficient 0.07) provide a smoother adaptation to the current load, reducing false volatility of forecasts.
However, as shown in the paper, the results achieved are preliminary and cannot be considered sufficient for industrial implementation without extensive research in the following areas: validation on long-term performance archives, taking into account seasonal and structural changes; development of methods for detecting distribution drift and automatic retraining; solving the problem of sparsity of data through Bayesian regularization or aggregation ensuring computational scalability with increasing spatial dimension; calibration of hyperparameters, adaptive to the type of load; building asymmetric metrics for the quality of forecasts, taking into account the cost of errors; integration with existing monitoring stacks; increasing interpretability for engineering personnel; comparative benchmarking with alternative machine learning methods; as well as stress testing the fault tolerance of the predictor itself.
Each of these challenges represents an independent research task, and their consistent solution will determine the roadmap for the further development of the project, the source codes of which are open to academic and industrial cooperation.
Оригинал на основном техническом блоге : Марковская цепь для DBA: эволюция, фильтрация и путь в промышленную эксплуатацию (возможны исправления и дополнения)
Версия 12.1 — важный эволюционный шаг, однако её точность, устойчивость и пригодность для реальных систем ещё предстоит доказать через серию масштабных исследований: от долгосрочной валидации и борьбы с дрейфом распределения до интеграции в мониторинговый ландшафт и обеспечения надёжности в нештатных ситуациях.
Дополнительные материалы по исследованию применения цепи Маркова в проекте pg_expecto
Прогнозирование аварийных ситуаций в сложных динамических системах, таких как СУБД PostgreSQL, сталкивается с фундаментальной проблемой нестационарности распределения наблюдаемых параметров и множественностью сценариев развития инцидентов.
В настоящей работе представлена эволюция марковской модели прогнозирования, прошедшей путь от статичной поглощающей матрицы с жёстко заданными критериями аварийности (версия 10.1.6) до самонастраивающегося итеративного механизма с динамически обновляемым перечнем критических состояний на основе эмпирического риска (версия 11.3), и, наконец, до текущей версии 12.1, где ключевым нововведением стала фильтрация переходов при оценке стабильности — исключение критических состояний и редких событий с числом переходов менее порогового значения.
Данная эволюция отражает постепенное осознание того, что надёжность прогноза определяется не только точностью вероятностных оценок, но и устойчивостью самой модели к выбросам и разреженным данным.
В статье последовательно анализируются архитектурные изменения, сравниваются подходы к определению аварийности, расчёту горизонтов и параметров забывания, а также формулируется комплекс открытых проблем, требующих решения для перехода к промышленной эксплуатации.
Первая реализация опиралась на предположение о стационарности и использовала фиксированные аварийные критерии. Модель работала с 189 состояниями, которые представляли собой комбинации трёх параметров — корреляции, тренда ОС и тренда ожиданий. Аварийным считалось только одно строгое условие: отрицательная корреляция при падающем тренде ОС и растущем тренде ожиданий.
Прогноз строился через поглощающую матрицу, пересчитываемую при каждом обновлении вероятностей. Горизонты были фиксированными — 1, 15, 30 и 60 минут. Достоверность оценивалась по пятибалльной шкале на основе объёма данных и стабильности вероятностей. Это было рабочее решение, но оно не учитывало, что реальные инциденты могут проявляться иначе, а параметры системы со временем меняются.
Методология заложеная в версия 11 принципиально отличается. Вместо жёсткого условия разработчики ввели таблицу critical_states, которая автоматически пополняется функцией refresh_critical_states на основе эмпирического риска из таблицы инцидентов. Теперь аварийные состояния определяются не раз и навсегда, а извлекаются из истории наблюдений.
Одновременно изменился сам механизм прогноза: поглощающая матрица уступила место итеративному расчёту с обнулением вероятностей критических состояний на каждом шаге. Горизонт стал единым и задаётся в конфигурации (по умолчанию 30 минут). Появились новые отчёты, в том числе mchain_quality_report, а достоверность стала штрафоваться за нестабильность.
Это был шаг к самообучающейся системе, но оставалась проблема: стабильность модели оценивалась по всем переходам, включая редкие и аварийные, что могло искажать реальную картину.
Последний релиз не вносит кардинальных архитектурных изменений, но существенно уточняет, как мы измеряем стабильность.
Главное нововведение — фильтрация при расчёте максимального изменения вероятностей переходов (max_prob_change).
Из анализа исключаются:
- переходы в критические состояния (те, что перечислены в critical_states);
- состояния, для которых за анализируемый период зафиксировано менее 200 переходов.
Это позволяет отсечь шум: редкие события и аварийные пики перестают влиять на оценку стабильности, делая её более репрезентативной. Кроме того, скорректированы параметры забывания по умолчанию — интервал уменьшен с 180 до 60 минут, а базовый коэффициент альфа — с 0.1 до 0.07. Такая настройка обеспечивает более плавную адаптацию к новым данным, снижая резкие скачки.
Фильтрация внедрена во все ключевые функции: mchain_check_sufficiency, mchain_forecast_reliability, mchain_reliability_report, evaluate_forgetting_params и report_stability_trend. Теперь каждый отчёт о надёжности учитывает только статистически значимые и некритические переходы.
Если обобщить различия, можно выделить несколько осей развития.
- Версия 10: жёсткое логическое условие, зашитое в код.
- Версии 11 и 12: динамический список critical_states, обновляемый по данным инцидентов.
- Версия 10: поглощающая матрица, перестраиваемая при каждом обновлении.
- Версии 11 и 12: итеративное обнуление вероятностей критических состояний без использования поглощающей матрицы.
- Версия 10: четыре фиксированных горизонта (1, 15, 30, 60 минут).
- Версии 11 и 12: единый горизонт, задаваемый в конфигурации (по умолчанию 30 минут).
- Версии 10 и 11: учитывались все переходы без исключений.
- Версия 12: исключены переходы в критические состояния и состояния с числом переходов менее 200.
- Версии 10 и 11: interval_minute=180, base_alpha=0.1.
- Версия 12: interval_minute=60, base_alpha=0.07.
Версия 12.1 — не революция, а эволюционное уточнение, которое делает модель более устойчивой к выбросам и редким событиям.
Благодаря фильтрации оценка стабильности стала объективнее, а прогнозы — достовернее в реальных условиях эксплуатации.
Однако пока рано говорить о промышленном внедрении инструмента: требуется много дополнительных исследований и тестирования для реализации методики на продуктивной нагрузке.
Среди ключевых направлений, нуждающихся в проработке, можно выделить следующие.
- Валидация на длительных исторических данных. Текущие эксперименты проводились на ограниченных выборках. Для подтверждения устойчивости модели необходимо протестировать её на многомесячных архивах производительности PostgreSQL с разнообразными паттернами нагрузки: сезонными пиками, миграциями данных, обновлениями версий СУБД и изменениями конфигурации. Только такая валидация позволит оценить, насколько модель сохраняет точность при смене эксплуатационных условий.
- Адаптация к нестационарности. Производительность реальных систем со временем меняется — растут объёмы данных, эволюционируют запросы, обновляется аппаратное обеспечение. Цепь Маркова первого порядка, предполагающая стационарность переходных вероятностей, может давать сбои в таких условиях. Необходимы исследования того, как часто нужно переобучать модель, какие механизмы обнаружения дрейфа распределения следует внедрить и как автоматически перестраивать пространство состояний при изменении характера нагрузки.
- Проблема разреженности данных. В версии 12.1 уже введён порог в 200 переходов для включения состояния в расчёт стабильности. Однако на продуктивных системах многие состояния могут оставаться редкими, особенно в начальный период наблюдения. Это ставит вопрос о разработке методов сглаживания (например, байесовской априорной регуляризации) или агрегации схожих состояний, чтобы повысить статистическую значимость оценок без потери чувствительности к аномалиям.
- Вычислительная масштабируемость. При росте числа наблюдаемых параметров пространство состояний может быстро разрастаться. В текущей реализации используется 189 состояний — комбинация трёх параметров. На продуктивной системе может потребоваться учёт дополнительных метрик (количество активных сессий, размер буферного кэша, интенсивность контрольных точек и т.д.), что приведёт к экспоненциальному росту числа состояний. Требуется исследование методов сокращения размерности и эффективных структур данных для хранения и обновления матрицы переходов в реальном времени.
- Калибровка гиперпараметров. В версии 12.1 скорректированы параметры забывания: interval_minute уменьшен с 180 до 60, а base_alpha — с 0.1 до 0.07. Однако оптимальные значения этих параметров могут существенно зависеть от конкретной рабочей нагрузки: для высокодинамичных систем требуется более быстрое забывание, для стабильных — напротив, более долгая память. Необходимы систематические исследования по автоматическому подбору гиперпараметров, возможно, с использованием методов оптимизации, адаптивных к текущим условиям.
- Оценка качества прогнозов на продуктивной нагрузке. В лабораторных условиях модель показывает обнадёживающие результаты. Однако на реальных системах цена ложноположительных и ложноотрицательных срабатываний совершенно иная. Ложное предупреждение может отвлечь администратора от действительно важных задач, а пропуск инцидента — привести к простою. Необходима разработка метрик качества, учитывающих асимметрию потерь, а также калибровка порогов срабатывания под конкретные SLA и бизнес-приоритеты.
- Интеграция с существующими системами мониторинга. Промышленное внедрение требует бесшовной интеграции с распространёнными стеками наблюдения (Prometheus, Zabbix, Grafana и др.). Это означает не только техническую совместимость по протоколам и форматам данных, но и согласование моделей данных: метрики, используемые цепью Маркова, должны соответствовать тем, что уже собираются в продуктивной среде, без необходимости доработки агентов сбора.
- Интерпретируемость для инженеров. Цепи Маркова дают вероятностный прогноз, но администраторам баз данных нужны не только цифры, но и понятные объяснения: почему модель ожидает инцидент, какие именно переходы между состояниями привели к такому выводу, на какие метрики следует обратить внимание в первую очередь. Требуются дополнительные исследования в области объяснимого искусственного интеллекта (XAI) применительно к марковским моделям.
- Сравнительные исследования с альтернативными подходами. На сегодняшний день не проведено систематического сравнения марковского подхода с другими методами прогнозирования — рекуррентными нейронными сетями, градиентным бустингом на временных рядах, скрытыми марковскими моделями или байесовскими структурными временными рядами. Без такого бенчмарка на репрезентативных датасетах сложно утверждать, что цепь Маркова является оптимальным выбором, а не просто удобной и интерпретируемой альтернативой.
- Тестирование на отказоустойчивость. В продуктивной среде модель должна корректно работать при сбоях в сборе данных, временной недоступности хранилища метрик, скачках задержек и других аномалиях инфраструктурного уровня. Необходимы стресс-тесты, моделирующие различные сценарии деградации самого механизма прогнозирования, чтобы гарантировать, что отказ модели не усугубит ситуацию в системе.
Таким образом, путь к промышленному внедрению лежит через серию масштабных исследовательских и инженерных работ: от валидации на больших данных до интеграции в существующий мониторинговый ландшафт и обеспечения надёжности в нештатных ситуациях.
Проект открыт для сотрудничества, и каждый из этих вызовов может стать отдельной темой для совместной разработки.
Исходный код, как и прежде, открыт и доступен в репозитории https://github.com/pg-expecto/markov_chain — каждый желающий может изучить детали реализации и внести свой вклад в развитие проекта.
Проведённый анализ трёх версий марковского прогностического инструмента демонстрирует последовательное улучшение его репрезентативности и робастности за счёт отказа от статичных допущений, внедрения эмпирически обновляемого списка критических состояний и, в особенности, введения фильтрации статистически незначимых и аварийных переходов при оценке стабильности. Скорректированные параметры забывания (интервал 60 минут, базовый коэффициент 0.07) обеспечивают более плавную адаптацию к текущей нагрузке, снижая ложную волатильность прогнозов.
Вместе с тем, как показано в работе, достигнутые результаты носят предварительный характер и не могут считаться достаточными для промышленного внедрения без проведения обширных исследований по следующим направлениям: валидация на многолетних архивах производительности с учётом сезонных и структурных изменений; разработка методов обнаружения дрейфа распределения и автоматического переобучения; решение проблемы разреженности данных через байесовскую регуляризацию или агрегацию состояний; обеспечение вычислительной масштабируемости при росте размерности пространства; калибровка гиперпараметров, адаптивная к типу нагрузки; построение асимметричных метрик качества прогнозов с учётом стоимости ошибок; интеграция с существующими стеками мониторинга; повышение интерпретируемости для инженерного персонала; сравнительный бенчмаркинг с альтернативными методами машинного обучения; а также стресс-тестирование отказоустойчивости самого предиктора.
Каждый из перечисленных вызовов представляет собой самостоятельную исследовательскую задачу, и их последовательное решение определит дорожную карту дальнейшего развития проекта, исходные коды которого открыты для академического и индустриального сотрудничества.
Share
