Мониторинг механизмов обработки данных в Monq

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

Объекты мониторинга и точки контроля

Мониторинг инфраструктуры Monq охватывает три ключевых направления:

• Сбор данных:
  • контроль активности потоков данных и наличия ошибок приема данных в журнале
  • контроль статуса сборщиков данных и наличия ошибок в журнале запусков
  • контроль статуса выполнения метрик-бриджей
  • контроль отсутствия/наличия блокировок со стороны лимитов через журнал блокировок
• Обработка данных:
  • контроль активности правил порогов и их статус
  • контроль создания и обновления порогов по настроенным правилам
• Автоматизация:
  • контроль статуса бизнес-процессов и истории их запусков
  • контроль выполнения сценариев в истории запусков

Периодический контроль работоспособности

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

Потоки данных и их блокировка

Потоки данных могут быть остановлены вручную или заблокированы системой при превышении лимитов. Проверить их состояние можно в разделе «Сбор (ETL)» → «Потоки данных».

Обратите внимание на состояние потока. Если поток остановлен, данные в него не поступают. При блокировке со стороны системы (например, из-за превышения лимитов или ошибок конфигурации) доступ к данным сценариев и правил порогов может быть ограничен.

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

Сборщики данных

Сборщики отвечают за сбор данных из внешних систем (API, базы данных, серверы). Проверить, как работают сборщики и успешно ли проходят их запуски, можно в разделе «Сбор (ETL)» → «Сборщики данных».

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

Чтобы понять причину сбоя, используется журнал запусков. В нем можно отфильтровать события по статусу (Ошибка/Предупреждение) и увидеть конкретный текст ошибки в колонке «Результат» (например, Object reference not set to an instance of an object или предупреждение о частичном сбое).

Метрик-бриджи

Метрик-бриджи преобразуют события и логи из индексов в метрические ряды по расписанию. Если бридж работает с ошибкой, метрики не обновляются, и пороги, построенные на них, не срабатывают. Проверить их состояние можно в разделе «Сбор (ETL)» → «Метрик-бриджи».

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

При возникновении ошибки в карточке бриджа появляется соответствующий статус с детализацией ошибки.

Правила порогов

Правила расчета порогов могут быть остановлены вручную или работать с ошибками, если для них не хватает данных. Проверить их состояние можно в разделе «Анализ и обработка» → «Правила порогов».

Обратите внимание на статус, в котором находится правило. Если правило находится в статусе «Ошибка», оно не может корректно рассчитать порог.

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

Бизнес-процессы

Бизнес-процессы отвечают за автоматизацию различных действий: отправку уведомлений, эскалаций, автоматическую регистрацию задач в ServiceDesk и т.д. Если бизнес-процесс выполняется с ошибкой, то соответствующая автоматизация не сработает. Проверить их состояние можно в разделе «Анализ и обработка» → «Бизнес-процессы». Обратите внимание на время последнего запуска. Если последний запуск завершился ошибкой, это отображается соответствующим индикатором.

Для диагностики сбоев в бизнес-процессах предусмотрен детальный журнал ошибок. Чтобы его посмотреть, откройте историю запусков конкретного бизнес-процесса. В ней отображается хронология всех запусков с указанием времени, длительности и статуса. При возникновении сбоя можно открыть конкретный запуск и увидеть сообщение об ошибке, а также состояние переменных на момент выполнения.

Лимиты и правила блокировок

Monq позволяет отслеживать потребление ресурсов (объем логов, количество метрик) и блокировать соответствующий функционал при превышении лимитов. В разделе «Настройки пространства» → «Лимиты» настройте правила блокировки (например, максимальный объем принятых сырых логов или количество метрик).

Если показатели превысят порог, заданный в одном из правил блокировки, функционал блокируется, и отобразится визуальное уведомление (например, "Выполнение сценариев автоматизации заблокировано").

⚠️ Блокировка не откладывает данные в очередь, а отменяет их обработку. Это означает, что данные за период блокировки не будут обработаны и не сохранятся в системе.

Чтобы понять, что именно вызвало блокировку, используется журнал блокировок. Здесь отображается время, тип правила, зона действия (Пространство или конкретный Поток) и результат (Заблокировано/Разблокировано). В колонке «Проверяемые правила» видно точное значение, которое превысило порог (например, Значение: 52322 при лимите 1 Б).

Автоматизация контроля ошибок

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

Внимание

⚠️ Чтобы инженерам было проще обслуживать сценарии автоматизации и разбираться в ошибках, заранее зафиксируйте правила их разработки: обработку Failed-пинов, именование, ревью, порядок передачи на поддержку. Без единых правил сопровождение сценариев контроля усложняется, а причины сбоев локализуются дольше.

Обвязка Failed-пинов в сценариях

В визуальном конструкторе сценариев (Automaton) у исполняемых блоков (функций) есть исходящий пин Failed. Он срабатывает, если блок не может выполнить свое действие. Например, это происходит при ошибке отправки HTTP-запроса, при неудачной попытке создать сигнал или при сбое в блоке связывания порога с КЕ. Логика в этом случае уходит в ветку Failed.

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

• Отправка уведомления на почту (SendEmail), в Telegram (SendTelegramMessage) или VK Teams (VkTeamsSendMessage).

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

• Логирование информации об ошибке для последующего анализа.

• Выброс исключения (ThrowError), чтобы явно прервать выполнение сценария.

Помимо обвязки пина Failed, для отслеживания ошибок потоков данных или сборщиков можно использовать стартовые блоки сценария (события запуска). Например, блок OnLogEvent позволяет запускать сценарий при появлении в потоке события, связанного с ошибкой, а OnRawLogEvent — реагировать на ошибки в обработчике потока до их индексации.

Рассмотрим пример настройки уведомления по ошибке в интерфейсе Monq. Сценарий запускается по расписанию и выполняет поиск конфигурационной единицы. Если поиск завершается ошибкой, срабатывает пин Failed, и сценарий переходит к блоку SetStatusFailed, который фиксирует ошибку в истории запусков. Далее управление передаётся блоку SendRawEvent, отправляющему уведомление в интерфейс через системный ключ pl.automaton.ui-notify.

В результате при возникновении ошибки в интерфейсе появится всплывающее уведомление с заданным заголовком и текстом. Если сценарий завершился со статусом Failed, откройте «Историю запусков» и разверните детализацию. Вы увидите, на каком шаге произошёл сбой. Например, что блок GetConfigItemByUniqueKey завершился с ошибкой, после чего выполнился SetStatusFailed.

Журналирование ошибок в специальном типе сигналов

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

Настройка автоматического создания сигнала при сбое сборщика данных

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

На схеме ниже показано, как связаны компоненты между собой. Два источника событий: «Статус сборщика данных» и «Мониторинг потока» передают информацию в единый сценарий мониторинга ошибок, который на основе этих данных принимает решение о создании сигнала.

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

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