Monq 9.2: как перестать тонуть в миллионах порогов и начать ими управлять

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

Представим контур мониторинга крупного федерального ритейла: 5 000 торговых точек, в каждой в среднем 25 наблюдаемых конфигурационных единиц (КЕ) — кассы, сетевое оборудование, Wi-Fi, локальные серверы, ИБП, IoT и интеграционные компоненты. Если на одну КЕ приходится в среднем 20 временных рядов с рассчитанным состоянием, система одновременно работает примерно с 2,5 млн открытых порогов.

Это иллюстративная модель масштаба, а не описание конкретного заказчика. И 2,5 млн порогов — не 2,5 млн алертов или инцидентов. Это состояния временных рядов, большинство из которых остаются в OK. Задача платформы — не вывалить их плоским списком на оператора, а превратить в управляемые представления по регионам, сервисам, владельцам, КЕ и уровням критичности.

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

В такой модели дежурная смена может работать следующим образом:

1. Вы начинаете смену с групповой карты своего региона или набора бизнес-сервисов, а не с общей таблицы на миллионы строк.

2. Стековый график показывает не только долю Critical/Major/OK, но и общее количество активных порогов. Если оно неожиданно падает, это может означать потерю телеметрии, а не внезапное оздоровление инфраструктуры.

3. Рубрикатор и MQL-фильтрация сужают очередь до нужных уровней, правил и КЕ. Сохранённый набор фильтров становится повторяемым представлением для всей смены.

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

5. Если прогноз показывает ожидаемый переход в Critical, заранее согласованный сценарий может выполнить проверку, создать задачу или запустить безопасное превентивное действие — ещё до фактического отказа.

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

В прошлой статье о Monq 9.0 мы рассказывали, как платформа вышла за пределы классического «зонтика»: научилась сама собирать метрики и логи, превращать события во временные ряды, связывать телеметрию с CMDB и ресурсно-сервисной моделью, а затем запускать автоматизацию. Релиз 9.2 отвечает на следующий вопрос: как эксплуатировать этот объём данных каждый день.

10 июля мы выпустили Monq 9.2.0. Если описать релиз одной фразой: пороги получили собственное рабочее пространство, научились учитывать расписание, автоматически находить свою КЕ в CMDB и хранить прогноз собственного состояния. Для работы на больших объёмах хранение порогов перенесено из PostgreSQL в ClickHouse, а связанный конвейер сервисов переработан.

Да, перед вами обзор продукта от вендора. Поэтому ниже не будет обещаний «предсказать любую аварию» и общих слов про AIOps. Разберём точную механику, условия нагрузочного теста, работу дежурной смены, нюансы обновления и честную границу между тем, что уже работает в 9.2, и адаптивными порогами, которые появятся в 9.3.

Ниже разберём:

• почему порог в Monq — отдельный рабочий объект, а не только условие CPU > 95%;

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

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

• как связать порог с КЕ без обязательного сценария Автоматона;

• что именно прогнозирует сервис 9.2 и как результат передаётся автоматизации;

• почему пороги переехали в ClickHouse, что показал тест на 2,5 млн открытых порогов и как правильно интерпретировать его результаты;

• что нужно проверить перед обновлением действующей инсталляции.

Сначала договоримся, что такое порог в Monq

Во многих системах порог — это часть правила: «если значение выше X в течение Y минут, отправить уведомление». После срабатывания вы получаете алерт, а само вычисленное состояние ряда часто нигде не существует как отдельная сущность.

В Monq порог живёт дольше одного срабатывания. Он формируется для конкретного временного ряда, хранит текущий уровень и историю переходов, метки и аннотации, связь с объектом мониторинга (конфигурационной единицей – КЕ), а теперь ещё и прогноз. Сигнал, инцидент или бизнес-процесс могут появиться уже как реакция на это состояние.

Такое разделение полезно по трём причинам.

Во-первых, состояние можно исследовать независимо от инцидента. Например, увидеть, что диск несколько раз переходил из OK в Major и обратно, хотя до Critical дело не дошло.

Во-вторых, порог можно использовать как слой нормализации. Источники данных разные, названия метрик разные, но на выходе команда получает единый набор уровней: OK, Info, Minor, Major, Critical, Fatal.

В-третьих, порог становится входом для автоматизации. Сценарий может учитывать не только текущий уровень, но и прогнозируемое ухудшение, принадлежность КЕ сервису, наличие технического обслуживания и другие атрибуты.

Именно вокруг этой модели построены основные изменения 9.2.

Что скрывается внутри одной торговой точки: аптечный формат

Расчёт выше объясняет масштаб, но не содержание этих 2,5 млн состояний. Чтобы показать второй уровень модели, команда внедрения собрала в Monq мониторинг торговой точки аптечного формата. Её состояние оценивается сразу в трёх измерениях.

Operation Health отвечает на вопрос, может ли точка сейчас обслуживать покупателей: работает ли касса, открыта ли смена, есть ли связь с «Честным знаком» и системой электронных рецептов.

Business Performance Health показывает, выполняется ли сам бизнес-процесс: как меняются выручка, количество чеков и средний чек. Например, если выручка упала на 50% относительно нормы, Monq должен показать отклонение, даже когда серверы, каналы связи и кассовое ПО формально остаются зелёными.

Administration Health контролирует риски, которые редко попадают на оперативный дашборд: свежий ли бэкап, были ли попытки восстановления, обновлены ли антивирусные базы.

Это не «дашборд для руководителя», а единая модель причин и последствий. Из бизнес-показателя вы переходите к аптеке как КЕ, её кассе, интеграциям и инфраструктуре; техническое событие оцениваете по реальному влиянию на обслуживание покупателей. Возможности 9.2 — календарные пороги, нативная связь с CMDB, прогноз и быстрый поиск по миллионам состояний — делают такую модель пригодной для ежедневной эксплуатации, а не только для демонстрации на экране.

Миллионы порогов под контролем: новый дашборд и три способа быстро получить нужный контекст

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

На экране есть три способа сократить пространство поиска.

MQL-фильтрация. В строке поиска можно собирать сложные условия по атрибутам порога. Синтаксис не приходится держать в голове целиком: интерфейс предлагает подсказки. Например, вы оставляете Critical и Fatal, затем сужаете выборку до рабочей группы платёжного контура, типа КЕ «Linux Server» и правила свободного места на диске. Это не отдельный дашборд, который кто-то должен однажды написать и потом поддерживать, а запрос к актуальному набору порогов.

Рубрикатор. Частые разрезы — уровни, правила, КЕ и карты РСМ — доступны без ручного ввода. Это особенно полезно в первые минуты инцидента, когда точный запрос ещё неизвестен: вы последовательно сужаете область от сервиса к проблемным объектам.

Карты порогов. Найденную выборку можно сохранить как личное или групповое представление вместе с фильтрами, набором столбцов и временным интервалом. Личная карта отвечает на вопрос «что нужно видеть мне», групповая — «какая единая очередь работы нужна смене».

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

Карточка порога вместо прыжков между экранами

При выборе строки открывается детальная карточка с тремя вкладками.

• Обзор показывает параметры порога, прогноз ухудшения, ссылки на правило и КЕ, а также метки и аннотации с поиском.

• История совмещает график временного ряда, уровни порога, таймлайн срабатываний и историю изменения значений; период можно менять, данные — приближать.

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

Так вы сокращаете типичный маршрут расследования. Не нужно отдельно искать правило, потом метрику, потом объект в CMDB и выяснять, не было ли такого же перехода вчера. Контекст собран вокруг конкретного состояния ряда и сразу доступен дежурной смене. Если случай укладывается в регламент, смена отрабатывает его самостоятельно; если нет, владелец сервиса получает не голый алерт, а уже собранные данные для решения.

Стековый график обнаруживает не только «красное»

На карте порогов есть стековый график: он показывает количество активных порогов и долю уровней во времени. На первый взгляд это просто сводка Critical/Major/OK, но у графика есть более интересное применение — контроль покрытия мониторингом.

Допустим, в Kubernetes-кластере обычно открыто около 12 000 порогов. После обновления их стало 8 000, причём почти все оставшиеся — зелёные. Обычный дашборд выглядит даже лучше, но на самом деле четверть рядов исчезла: не отработало автообнаружение, изменились метки или часть агентов перестала отправлять данные. Провал общего количества порогов виден на таймлайне сразу.

Обратная ситуация — автоскейлинг. Число экземпляров выросло в три раза, вместе с ним выросло количество порогов, но доля проблемных осталась прежней. Это не «шторм алертов», а ожидаемое изменение состава наблюдаемых объектов. Стековый график помогает отличить изменение инфраструктуры от деградации её здоровья.

Один порог не обязан быть одинаковым в понедельник утром и ночью 31 декабря

Фиксированная граница удобна своей определённостью, но реальная система живёт по календарю. Ночная пакетная обработка закономерно нагружает БД сильнее дневного API. В дни массовой продажи билетов нормальный RPS в несколько раз выше. В нерабочее время отсутствие чеков у кассы — норма, а в рабочее — возможный инцидент.

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

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

Другой пример — сеть аптек. До открытия смены нулевое число чеков нормально. После открытия — уже нет. В день инвентаризации ожидаемая динамика отличается от обычной субботы. Календарный блок позволяет менять трактовку метрики там, где вы заранее знаете контекст, а не пытаться «выучить» очевидное расписание статистической моделью.

Справедливый вопрос: а как же бейзлайны, зачем вообще расписание, если можно построить адаптивный порог? У статического и адаптивного подходов разные задачи. Статические пороги вы используете, когда чётко знаете границу: загрузка CPU не должна превышать 90%, свободное место на диске — падать ниже 10%. Здесь важна детерминированность и предсказуемость.
Адаптивные пороги (бейзлайны) полезны, когда заранее неизвестно, какое значение считать нормой: например, количество чеков в час или RPS API зависят от времени суток, дня недели и сезона. Такие методы строят границы на основе истории, но они менее точны и требуют больше данных и контекста для корректной работы. Оба подхода имеют своё место в мониторинге. В Monq 9.2 мы реализовали гибкие статические пороги с учётом времени. Адаптивные пороги появятся в 9.3 — и на выбор будут доступны сразу два метода: IQR и перцентильный.

Связь с CMDB теперь настраивается в самом правиле

Порог без контекста отвечает только на вопрос «какая метрика вышла за границу». Чтобы понять влияние, владельца и маршрут эскалации, его нужно связать с конфигурационной единицей.

До 9.2 для такой привязки требовался сценарий нашего движка автоматизации «Автоматона». Это давало максимальную гибкость, но повышало порог входа: даже стандартное сопоставление приходилось описывать отдельной логикой. Теперь связь встроена непосредственно в правило формирования порога.

Доступны три режима.

1. По ID КЕ автоматически. Если данные собирает Monq, идентификатор КЕ добавляется в метки ряда (labels), и порог находит объект без участия пользователя.

2. По ключевым атрибутам. Для рядов из сторонней системы выбирается тип КЕ и сопоставление её ключевых атрибутов с метками ряда. Например, instance и адрес узла можно использовать, чтобы найти нужный сервер.

3. Через сценарий Автоматона. Режим остаётся для нестандартной логики и обратной совместимости.

Отдельно задаётся поведение, если КЕ не найдена: оставить порог непривязанным либо сгенерировать событие для бизнес-процесса. Второй вариант полезен как контроль качества CMDB. Новая метрика появляется в мониторинге, но объект не найден — это не тихая потеря контекста, а задача на разбор: возможно, автообнаружение сработало быстрее процесса регистрации КЕ или изменился ключевой атрибут.

В динамической инфраструктуре новый сервер, pod или сетевое устройство сразу получает порог с привязкой к КЕ — владельцем, зависимостями и местом в ресурсно-сервисной модели. Дальше одинаково работают анализ влияния, маршрутизация сигнала и автоматизация.

Прогноз: не адаптивный порог, а предсказание переходов состояния

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

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

• Для интерфейса и аналитики — полный прогноз на весь горизонт записывается в ClickHouse (вместе с порогом). Именно эти данные вы видите на дашборде и в карточке порога.

• Для автоматизации — в событие генерации порога добавляется JSON с прогнозными точками, но только теми, где ожидается смена уровня, отличного от текущего расчетного.

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

Что происходит с моделью под капотом

Проверка достаточности данных. Для ряда задаются минимальное число измерений и период релевантности. Например, можно потребовать не менее 500 точек за последние семь дней. Если выборки недостаточно, модель не строится, а в пороге явно фиксируется причина. Это лучше уверенного прогноза по трём случайным точкам.

Автоопределение сезонности. Одно правило может охватывать сотни рядов с разным поведением. Сервис анализирует каждый ряд и определяет наличие и период сезонности на основе преобразования Фурье. Вам не нужно вручную назначать «суточную» или «недельную» сезонность всем метрикам правила.

Дообучение и полное переобучение. Новые точки используются для обновления модели. Если характер ряда изменился — например, появилась или исчезла сезонность, — запускается полное переобучение, но не чаще одного раза в сутки, чтобы не создавать неконтролируемую вычислительную нагрузку.

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

Очистка. Если данные по ряду не поступают более пяти дней, его модель удаляется. Для динамических сред это обязательная гигиена: без неё модели давно исчезнувших pod и краткоживущих заданий будут бесконечно занимать ресурсы.

Три кейса, где прогноз полезнее ещё одного алерта

1. Диск заполнится во время ночного окна. Сейчас занято 82%, Critical начинается с 90%. Фиксированный порог ещё молчит. Прогноз показывает пересечение границы через шесть часов — уже после ухода дневной смены. Бизнес-процесс создаёт задачу на расширение тома или безопасную очистку до начала ночных работ. Значения в примере условные; принцип в том, что реакция запускается по ожидаемому уровню и времени, а не после факта.

2. Растёт отставание потребителя Kafka. Текущее значение допустимо, но скорость накопления очереди изменилась после релиза. Monq прогнозирует Major, связывает порог с consumer group и сервисом в CMDB, а Автоматон может запросить дополнительные метрики, проверить число реплик и выполнить заранее согласованное масштабирование. Если автоматическое действие запрещено, дежурная смена всё равно получает не просто сообщение «lag высокий», а запас времени, контекст и понятный следующий шаг.

3. Бизнес-метрика падает при зелёной инфраструктуре. В аптеке доступны сервер, касса и внешние интеграции, но количество чеков и выручка идут ниже ожидаемой траектории. Такой ряд можно обрабатывать тем же конвейером, что CPU или свободное место. Вы видите, что проблема ещё не проявилась техническим Critical, но уже влияет на процесс. Это и есть переход от мониторинга компонентов к мониторингу работы бизнеса.

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

Почему пороги переехали из PostgreSQL в ClickHouse

Переход Monq от зонтичного мониторинга к концепции единой платформы мониторинга закономерно увеличил число временных рядов и порогов. Сценарий работы с ними при этом в основном аналитический: выбрать большой набор записей, отфильтровать по нескольким атрибутам, агрегировать уровни во времени, быстро листать результат. На миллионах открытых порогов прежняя архитектура хранения стала ограничивать интерфейс.

В 9.2 хранение порогов перенесено из PostgreSQL в ClickHouse. Это не косметическая замена БД и не утверждение, что колоночное хранилище лучше для любой задачи. Здесь оно соответствует конкретному профилю нагрузки: большим выборкам, фильтрации и агрегациям по миллионам записей.

Для проверки мы сравнили 9.1.1 и 9.2.0 на 2,5 млн открытых порогов со сложными фильтрами.

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

На практике важны не абстрактные «разы», а изменение самого сценария работы. Запрос перестал быть операцией, во время которой открывают соседнюю вкладку и забывают, что искали. Вы можете последовательно уточнять фильтр, а таблицу использовать как рабочую очередь во время инцидента.

В поставку входит мигратор, который при обновлении переносит существующие пороги из прежней схемы хранения в ClickHouse. Отдельно оптимизирован сервис сигналов: для часто используемого фильтра по названию с оператором «Содержит» добавлен специальный индекс. На крупных инсталляциях предварительная оценка показала ускорение запросов на 20–50% для 60% карт, поэтому индекс включили в стандартную поставку.

Что ещё изменилось вокруг порогов

Главная тема релиза легко заслоняет десятки небольших изменений. Ниже — те, которые видны в ежедневной работе.

MetricBridge: меньше слепых зон на границе окна

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

Зачем задерживать расчёт? Представим, что правило каждую минуту считает ошибки по логам за предыдущую минуту, но часть событий приходит с опозданием из-за буфера агента или брокера. Без задержки окно уже рассчитано, поздние события в метрику не попадут. Небольшая управляемая задержка позволяет дождаться данных и убрать слепую зону на границе интервала. Конкретное значение выбирается по фактическому распределению задержек источника.

Плагины и контент-паки

• Linux Server Standard — готовые сценарии быстрого старта мониторинга Linux-серверов агентским и безагентским способом.

• Kafka — подписочная модель получения событий из брокера через плагин агента.

• SysLog — пользовательские регулярные выражения для нестандартных форматов в дополнение к встроенным RFC.

• WinInfo — подключение к удалённым узлам с доменными учётными записями.

• Битрикс24 — действия для алертинга и работы с задачами корпоративного портала.

Ценность здесь не в длине списка интеграций. Путь «получить данные → нормализовать → построить порог → связать с КЕ → запустить действие» закрывается типовыми компонентами, а low-code остаётся для действительно нестандартной логики.

Составные карты РСМ и общий доступ между группами

Карту ресурсно-сервисной модели теперь можно опубликовать другой рабочей группе. Также появилась возможность собирать составную карту из карт нескольких групп.

Практический вариант: сетевики, DBA и команда приложений сохраняют собственные карты с корректными правами и ответственностью. Рабочая группа дежурной смены собирает из них единое представление сервиса, не получая лишних административных полномочий. Это лучше, чем поддерживать ещё одну вручную скопированную карту, которая устаревает отдельно от исходных.

В этом же релизе обновлён экран метамодели CMDB. Изменение адресовано прежде всего администраторам, которые поддерживают структуру типов КЕ и связей, на которой затем строятся привязка порогов, карты РСМ и анализ влияния.

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

Закрытые пороги теперь очищает системный сервис с настройкой из интерфейса пространства. На крупных инсталляциях, где ежедневно может открываться 500 000 и более новых порогов, политика хранения — часть архитектуры, а не уборка «когда закончится диск».

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

Как обновляться: короткий чек-лист

Релиз затрагивает хранение, правила порогов и сервисы прогнозирования, поэтому обновление стоит воспринимать как архитектурное, а не как замену нескольких контейнеров.

1. Проверьте требования и резервное копирование. Зафиксируйте текущую версию, объём открытых и закрытых порогов, сроки хранения и доступный ресурс для переноса данных.

2. Инвентаризируйте старые сценарии привязки к CMDB. Отдельно найдите правила с ThresholdsProcessor. Не включайте одновременно старый механизм и новую нативную связь.

3. Спланируйте отказ от ThresholdsProcessor. Перенесите логику в ThresholdsToCmdbBinder или во встроенное сопоставление. Старый механизм поддерживается в 9.3 и 9.4, но откладывать этот переход до последнего релиза не стоит.

4. Проверьте качество меток (labels). Автоматическая связь с КЕ и полезная MQL-фильтрация зависят от стабильных идентификаторов и атрибутов. Обновление — хороший повод найти ряды с пустым instance, разным написанием имени узла и дублирующими ключами.

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

6. Создайте рабочие очереди. Не переносите в новый экран структуру старых дашбордов один к одному. Сформируйте отдельные представления для дежурной смены, DBA, сети и владельцев сервисов.

7. Проверьте исчезновение данных. После обновления сравните количество активных порогов и состав КЕ до и после переноса в ClickHouse. Зелёный экран при пропавшей телеметрии — не успешное обновление.

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

И, конечно, используйте официальную инструкцию обновления для своей редакции и топологии установки. Чек-лист выше не заменяет регламент, а показывает места, где чаще всего требуется ваше решение.

Вместо заключения: релиз не про «ещё один дашборд»

После Monq 9.0 платформа научилась принимать существенно больше телеметрии и работать как единый слой мониторинга и наблюдаемости. Следующая проблема была неизбежна: данные нужно не только собрать, но и превратить в управляемую систему состояний.

Monq 9.2 решает именно эту задачу.

• Порог стал отдельным рабочим объектом с историей, прогнозом и контекстом.

• Миллионы состояний можно фильтровать и просматривать без минут ожидания.

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

• Связь с CMDB настраивается без обязательного low-code сценария.

• Прогноз можно передать автоматизации и начать действие до фактического Critical.

• Очистка, перенос данных и сохранение настроек микросервисов стали частью штатной эксплуатации.

Вы можете заранее определить, что система делает сама, что подтверждает дежурная смена и в какой момент действительно нужно подключать владельца сервиса. Порог становится точкой входа в расследование: рядом находятся история ряда, правило, КЕ, её место в РСМ и прогноз переключения уровня. Типовой инцидент больше не приходит сильному специалисту в виде голого сообщения «что-то красное»: до него доходят уже собранный контекст, результаты первичных проверок и только те случаи, для которых не нашлось безопасного стандартного действия.

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

Поэтому 9.2 формально остаётся минорной версией, но по сложности разработки и глубине изменений сопоставима с мажорной. Мы меняли не внешний слой интерфейса, а путь от временного ряда до оперативного решения.

Новый экран порогов доступен и в Community Edition. Если хотите проверить подход на своей телеметрии, можно начать с одного практического сценария: свободное место на диске, lag очереди или бизнес-метрика из логов — и пройти весь путь от ряда до прогноза и автоматического действия.

Полезные ссылки:

• Документация: экран управления порогами

• Документация: настройка правил порогов

• Документация: MetricBridge

• Документация: управление конфигурацией микросервисов

• Скачать Monq Community Edition

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