Обновление 9.0.0 (10.10.2025)
Цели и задачи Monq 9
Наша команда рада представить новую, уже 9-ю по счету, версию нашего продукта Monq. Поскольку мы двигаемся от зонтичной системы к полнофункциональной all-in-one платформе мониторинга, в новой версии серьезным образом был переработан модуль сбора данных Collector (ETL).
Мы преследовали две основные цели:
- Значительно ускорить прием логов и сделать Monq отличным инструментом для их сбора;
- Обеспечить удобный инфраструктурный мониторинг и сбор данных с конечных устройств.
И нам кажется, мы этого достигли. Теперь нет необходимости при внедрении Monq думать о первичных системах мониторинга (Elastic или Zabbix, например) — все это можно получить, используя только Monq. Другое дело, если они у вас уже есть — оставляйте и пользуйтесь Monq как зонтиком. Выбор, как всегда, за вами.
1. Сборщики данных
Одним из основных нововведений стало появление сборщиков данных (Data Miners) — это специальные задания, которые собирают данные по определенным алгоритмам. Их можно запускать как на агентах Monq, так и при помощи модуля безагентского мониторинга.
Сборщики стали следующим этапом развития заданий в потоках, которые вы настраивали в Monq 8. Теперь потоки отвечают только за прием и преобразование данных, а функция сбора данных выделена отдельно в сборщики.
Что же такого нового в сборщиках в отличие от заданий потоков?
- Сборщики — это самостоятельная сущность, позволяющая настроить «шаблон» сбора данных с устройств, БД, ОС, внешних систем и т.д. То есть если вам уже не нужна какая-нибудь интеграция и вы удалите поток, сборщик останется и его можно будет использовать при настройке аналогичной интеграции. Так как сборщики теперь «живут отдельно» от потоков, они обзавелись собственным разделом в системе, который позволяет:
- Управлять сборщиками — создавать, изменять настройки, управлять их состоянием и удалять, а для удобства работы предусмотрены еще и массовые действия;
- Производить поиск, фильтровать по широкому набору параметров, в том числе и по пользовательским тегам;
- Отслеживать статусы выполнения каждого экземпляра сборщика в специализированном журнале с возможностями фильтрации и поиска.
- Расширены настройки параметров запуска — появилась возможность связи этих параметров с атрибутами объектов CMDB (КЕ). Теперь вы можете при помощи фильтра CMDB формировать перечень КЕ, для которых будет выполнять задание сборщик. Например, для всех ваших коммутаторов можно настроить один сборщик ICMP, который будет выполняться для всех КЕ с типом «коммутатор», а значение IP-адреса будет взято из соответствующего атрибута в CMDB. Появляется новый коммутатор в CMDB — автоматически он становится на мониторинг. Фильтры вы можете делать сколь угодно сложными. Если сборщик связан с КЕ, то в карточке этой КЕ вы его тоже увидите, таким образом легко понять, какие данные по КЕ собираются.
- Улучшены функции распределения заданий по агентам. Доступны три варианта:
- Система — сбор данных выполняется системой без участия агентов;
- На любом агенте из списка — сбор данных выполнит первый ответивший агент из доступных;
- На всех агентах списка — сбор данных выполнится на каждом доступном агенте.
- Добавлена возможность запускать бизнес-процессы (автоматизированные действия) по изменению статуса сборщика. Например, если сборщик стал выполняться с ошибками, вы можете настроить сценарий оповещения или запустить какой-нибудь специальный скрипт.
Документация: Сборщики данных
2. Потоки данных
Вторая обязательная составляющая получения данных — это потоки (streams). В 9-й версии Monq потоки необходимы для приема данных, преобразования и дальнейшей маршрутизации.
Благодаря модернизации ETL-тракта мы радикально нарастили мощность приема логов и событий.
На предварительном нагрузочном тестировании один экземпляр позволял принимать, парсить и сохранять 16 000 событий по 1 КБ в секунду. Таким образом, удалось достичь цифры приема 1,4 ТБ логов в сутки! И это без горизонтального масштабирования сервисов.
Так что если вам нужен высокопроизводительный enterprise-инструмент сбора событий и логов (например, для замены Splunk или ELK), пора присмотреться к Monq 9.
Сейчас проводим полноценное нагрузочное тестирование с разными парсерами, логами, с подключением/отключением ingress-контроллера. Как только будем готовы, обязательно поделимся с вами результатами.
Итак, в 9-й версии вас ждут следующие изменения в функционале потоков (streams):
- Потоки разделились по типам принимаемых данных: логи / метрики. В 9-й версии необходимо указывать тип данных для потока, от этого зависят дальнейшие варианты обработки и маршрутизации. Типизация — это цена за производительность и функциональность.
- Настроек в потоке стало меньше — все настройки, связанные с заданиями, переехали в сборщики, об этом подробно рассказано выше.
- Появились опции маршрутизации для логов. В настройках потока можно выбрать, что делать с полученными логами: сохранять, или отправлять на постобработку, или все вместе. Когда это необходимо? Например, опция «Только сохранение» полезна, когда нужно накопить данные, а только потом запустить сценарий корреляции: «Создай инцидент, если за последние 10 минут были зарегистрированы события А, B и С». Также очень полезно в случае SNMP-trap, когда поток таких событий может забить тракт постобработки. Второй случай применения — когда нужно, наоборот, направлять событие на сценарии «Автоматона» без сохранения, это сценарии синхронизации CMDB. Теперь можно выбрать нужную опцию маршрутизации и не создавать лишнюю нагрузку на компоненты системы.
- Мультинабор инструментов для нормализации (парсинга) логов. В зависимости от выбранного формата поступающих логов (доступен широкий набор форматов данных: JSON, XML, Loki, Regex, Syslog RFC3164/5424 и т. д.) система устанавливает стандартный обработчик. При этом, если вам не хватает стандартного обработчика, доступны регулярные выражения и строковые преобразования. Ну а если попалось что-то сложное и вы Monq-GURU, всегда можно написать сценарий парсинга на встроенном low-code движке «Автоматон».
- Встроенные обработчики и расширение форматов для метрик. В 9.0 доступны встроенные парсеры для следующих форматов метрик: PrometheusRemoteWrite (Protobuf), PrometheusPlain, OpenTsdbJson, ZabbixStreamsNdJson.
- Журнал ошибок с возможностью поиска и фильтрации для оперативной диагностики при неработоспособности потоков.
- Специальное стартовое событие «Мониторинг потока» в бизнес-процессах. Как и раньше, поток позволяет отслеживать поступление данных, и при их отсутствии может фиксировать ошибку не только в журнале, но и генерировать специальное служебное событие, по которому можно стартовать бизнес-процесс в Monq, чтобы оповестить ответственного или запустить скрипт для восстановления интеграции.
Документация: Потоки данных
3. Monq агент 3.0
В связи с масштабными изменениями по сбору и приему данных в системе агент также получил новую версию — 3.0.
Дополнительно агент 3.0 получил возможность самостоятельно отправлять собранные данные — раньше за этот функционал отвечали только плагины.
Новый агент сможет работать как с плагинами новой версии, поддерживающими такую функцию, так и со старыми.
Подход отправки результатов агентом, а не плагином, станет стандартом и старые плагины будут обновлены в старших версиях системы.
Плагины для сбора данных
По самым частым запросам от наших пользователей и в тему инфраструктурного мониторинга к выпуску 9 версии мы официально публикуем следующие плагины:
- ICMP — плагин для получения метрик от сетевых устройств по протоколу ICMP;
- HttpProbe — плагин для получения метрик доступности сайтов или API;
- NodeInfo — плагин для получения метрик производительности машин под управлением ОС Linux локально или удаленно (SSH);
- WinInfo — плагин для получения метрик производительности машин под управлением ОС Windows локально или удаленно (WMI). Удаленный сбор метрик работает только через агент Monq, запущенный в режиме проксирования запросов на машине с ОС Windows.
Также новые возможности (и соответственно новую версию) получили «старые» плагины:
- Плагин для работы с Zabbix (ZabbixEventsDataFlow) был адаптирован под новые требования аутентификации в Zabbix версии выше 7.0;
- Для плагинов SNMP-trap, Syslog, TCP/UDP, Tail был расширен функционал в части идентификации хоста, на котором установлен внешний агент, и самого агента, выполняющего сбор данных.
На текущий момент в работе находятся и с ближайшими релизами будут доступны новые плагины:
- SNMP — плагин для получения метрик от сетевых устройств по протоколу SNMP;
- IPMI — плагин для получения метрик от сетевых устройств по протоколу IPMI;
- Kafka — плагин для получения данных с Kafka.
4. Новые экраны для работы с данными
Как показывает практика, быстрого и функционального сбора данных недостаточно для полноценной работы с данными — необходимы инструменты для визуализации и анализа всего, что было собрано. Поэтому в системе мы реализовали новый экран для работы с метриками и улучшили функциональные возможности экрана для работы с событиями и логами.
Новый экран метрик
Появился новый раздел «Метрики». В предыдущих версиях поиск и анализ метрик был возможен непосредственно при настройке порогов.
В Monq 9 появился централизованный Metrics explorer: раздел, в котором можно гибко исследовать все метрики системы. По сути, это встроенный Grafana-like интерфейс: сверху список метрик, по центру можно выбрать представление временных рядов в виде графика, списка или таблицы.
Новый экран доступен пользователям в разделе «Просмотр данных» основного меню, а интерфейс позволяет:
- Определить период выборки и частоту обновления данных для исследования временных рядов;
- Создать один или несколько запросов на PromQL для просмотра данных из разных источников (в качестве источников доступны потоки с типом «Метрики») или с разным набором меток;
- Проанализировать полученные временные ряды с помощью общего графика, табличного или списочного представления;
- Скрывать / отображать полученные временные ряды на графике для удобства анализа;
- Удобно использовать строку запросов в качестве поисковой с подсказками по названиям доступных метрик, а также функциями быстрого копирования / дублирования запросов.
Документация: Метрики
Обновленный экран событий и логов
Раздел «События и логи» был переименован в «Логи», переехал в раздел «Просмотр данных» основного меню и получил следующую функциональность, которой не было в 8-й и более ранних версиях:
- Индексы — упрощенные структурированные табличные представления логов для быстрого поиска на экране логов и преобразования логов в метрики (подробнее дальше);
- Сохраняемые «Карты логов», по аналогии с «Картами сигналов», позволяют сохранить не только фильтр, как это было в ранних редакциях, но и определить уровень доступа к карте (личный или общий), вид отображения данных (табличный или список) и набор отображаемых полей;
- Новый визуальный конструктор запросов, интегрированный в строку запросов, по аналогии с экраном сигналов;
- Обновленное представление самого лога — теперь он открывается как карточка в правой части экрана, а не внутри таблицы, как раньше;
- В списке логов появилась информация о потоке, из которого был получен лог, с возможностью перехода к нему;
- Полнотекстовый поиск по всем полям логов, включая массивы значений, стал возможен благодаря изменению структуры сохраняемых данных («уплощение» JSON-формата) для ускорения ETL.
После обновления на 9-ю версию необходимо заново настроить и сохранить фильтры (теперь это Карты логов). Все ранее сохраненные фильтры становятся неактуальными из-за изменения структуры данных и будут удалены при обновлении системы.
Документация: Логи
5. Индексы: сервис быстрого доступа к данным из логов
По сути индекс — это отдельная таблица с сокращенным набором полей из лога, там есть все, что необходимо для работы, и ничего лишнего.
Индексы обязательно используются в сервисе метрик-бридж (подробнее дальше), что позволяет нам не нагружать хранилище фильтр-запросами. А также (по желанию) на экране и в картах логов для ускорения поиска и просмотра.
Индекс позволяет записывать не только вновь поступающую информацию, но и предзаполнить его уже хранящимися данными за выбранный промежуток времени при создании.
Доступ к сервису организован через раздел «Логи» (не вынесен в основное меню, так как является вспомогательным сервисом) из списка выбора индексов.
Интерфейс сервиса позволяет пользователю:
- Просматривать список настроенных индексов с возможностью поиска по названию;
- Просматривать карточку индекса со всеми настройками, а также списками метрик-бриджей и карт логов, которые используют выбранный индекс;
- Управлять индексами:
- Создавать с возможностью указания различных источников данных (потоков) и полей (до 15 полей в одном индексе) с определением значений по умолчанию;
- Редактировать — в текущей версии доступно изменение только названий у созданного индекса, для изменения параметров индекс необходимо пересоздать (в старших версиях возможности будут расширены);
- Удалять — при условии, что индекс не используется в картах логов или метрик-бриджах.
Документация: Индексы
6. Метрик-бридж: сервис преобразования логов в метрики
Очень часто требуется преобразовать собранные логи во временные ряды и далее работать с ними как с метриками — генерировать пороги, прогнозировать поведение и находить аномалии. Также это нужно для извлечения бизнес-данных из логов и может быть полезно даже для корреляции событий.
Теперь при помощи сервиса метрик-бридж вы можете задавать специальные правила трансформации логов в метрики.
Правила запускаются с определенной пользователем периодичностью и позволяют решить следующие задачи:
- Посчитать количество — функция возвращает количество событий за период времени. Например, преобразуем из логов в метрику количество ошибок в единицу времени. И далее уже отслеживаем аномалии на полученном временном ряду.
- Проверить булево правило — функция возвращает значение 1 или 0 в зависимости от выполнения условия запроса.
- Выполнить преобразование — функция преобразует одно из полей в значение временного ряда. Полезно, если внутри лога спрятана бизнес-метрика.
Ну и, конечно, как и везде в Monq, мы применяем архитектуру массовой обработки данных.
Для этого в сервисе метрик-бридж предусмотрены разделители — выбираемые поля, которые сохраняются в метрике в качестве меток.
Они позволяют при помощи одного правила обрабатывать множество однотипных задач, не создавая дублей правил. В случае если метки-разделители выбраны, вычисляется количество событий для каждого сочетания значений этих меток.
Все сгенерированные сервисом метрик-бридж метрики сохраняются в коллекторе с указанием в качестве источника данных системного потока - Metrics Bridge Streams (для каждой рабочей группы он свой).
Новый сервис доступен пользователям в разделе "Сбор (ETL)" основного меню, а интерфейс позволяет:
- Просматривать список бриджей с возможностью поиска и гибкой фильтрации по различным параметрам;
- Просматривать карточку бриджа со всеми настройками с возможностью их изменения;
- Управлять бриджами:
- Управлять состоянием бриджей — запускать или останавливать исполнение правила преобразования выбранного бриджа;
- Создавать бриджи с указанием индекса, из которого будут браться данные;
- Редактировать все параметры бриджа;
- Удалять выбранный бридж.
Документация: Метрик-бриджи
7. Комментарии к сигналам
Работа с инцидентами — командная игра. Поэтому в Monq 9 мы добавили возможность оставлять комментарии непосредственно в карточке сигнала (инцидента).
Теперь, когда происходит какой-то инцидент, все действия и наблюдения можно логировать прямо в нем.
Комментарии видят все участники команды, работающие с инцидентом, что облегчает передачу информации при смене дежурных. Комментарии остаются доступными и после архивации сигнала — фактически, получается таймлайн устранения инцидента.
Работа с комментариями доступна пользователям в разделе «Сигналы», интерфейс позволяет пользователю:
- Отображать столбец с комментариями как один из параметров в представлении карты сигналов;
- Просматривать / добавлять / изменять / удалять комментарии в карточке активных сигналов;
- Просматривать комментарии в карточке архивных сигналов.
8. Обновленная система доступа к КЕ (расшарка прав)
Публикация КЕ пришла на смену существующим «расшаркам», чтобы снизить нагрузку на систему и сделать работу с картами РСМ более производительной. Постоянные запросы проверки прав сторонних РГ замедляли загрузку списка КЕ на картах, где используется большое количество расшаренных КЕ.
Механика так называемых подписок не подразумевает привычную ранее выдачу каких-либо прав, а лишь делает видимой ключевую информацию о КЕ подписчику. Сама подписка на стороннюю КЕ осуществляется путем создания связи влияния от опубликованной КЕ к зависимой.
Права на объекты в РСМ внутри РГ остаются неизменными.
- Публикация КЕ может быть как адресной — для одной или нескольких РГ, так и для всех РГ, включая будущие;
- Управление публикациями осуществляется во вкладке «Публикации» в оперативном центре или в карточке самой КЕ;
- Добавлена массовая публикация КЕ путем выбора соответствующего пункта в массовых действиях в списке КЕ на Оперативном центре и в таблице CMDB;
- Сценарии автоматизации также получили функции по управлению публикациями.
Основная цель использования карт РСМ — визуализировать и анализировать связи влияния между КЕ, чтобы оперативно находить корневые причины инцидентов и оценивать impact.
Опубликованные КЕ имеют характерное визуальное отличие в виде иконки РГ их владельца, что позволяет легко идентифицировать, что проблема исходит от «чужой» РГ.
Опубликованные КЕ отображаются на следующих экранах:
- Список КЕ - опубликованные КЕ будут являться дополнением к КЕ текущего контекста;
- Граф РСМ;
- Таблица CMDB;
- Анализ первопричин (RCA);
- Диаграмма здоровья КЕ;
- Таблица сигналов.
Все опубликованные КЕ будут иметь сокращенное контекстное меню для ознакомления с основной информацией о КЕ. Если вы состоите и в РГ опубликованной КЕ, контекстное меню будет полным.
9. Расширение возможностей автоматизации
В Monq 9 существенно расширились возможности автоматизации — бизнес-процессы теперь позволяют организовать self-monitoring сбора данных, а сценарии автоматизации получили комплекс новых функций для работы с обновленным функционалом.
Бизнес-процессы
- Для оперативного реагирования на нештатные ситуации при сборе и обработке данных теперь можно использовать сразу бизнес-процессы. Для этих задач появились новые стартовые блоки:
- Статус сборщика данных — позволит запустить бизнес-процесс, если при сборке данных что-то пошло не по плану.
- Мониторинг потока — позволит запустить бизнес-процесс, если в поток перестали поступать данные.
Данный функционал пришел на смену отправке событий мониторинга потоков в сценарии автоматизации, чем упростил процесс настройки мониторинга системы.
- Для оперативного контроля за работой над инцидентами (сигналами) бизнес-процессы позволяют отслеживать изменения (добавление / редактирование / удаление) комментариев к сигналам. Для этих задач был расширен функционал условий запуска в стартовом блоке «Сигнал».
- Для того чтобы у пользователей было однозначное понимание, какое время обрабатывает блок Business Calendar, в интерфейсе добавлена подсказка с указанием часового пояса (UTC ±0).
Функции для сценариев автоматизации
-
Новые функции
FilterSignalComments
— возвращает список комментариев к сигналам согласно условиям фильтра;CreateConfigItemPublicationBatch
— публикация списка КЕ для одной или нескольких рабочих групп;DeleteConfigItemPublicationBatch
— удаление публикации списка КЕ для одной или нескольких рабочих групп.
-
Измененные функции
В связи с изменениями системы прав КЕ изменились функции их создания и обновления.
- Появилась возможность опубликовать КЕ сразу при ее создании как для одной или нескольких РГ, так и для всех РГ сразу — в функциях:
CreateConfigItem
CreateConfigItemExpanded
CreateConfigItemsBatch
- При необходимости опубликовать существующую КЕ для всех РГ (или отменить общую публикацию) воспользуйтесь функциями обновления КЕ:
UpdateConfigItem
UpdateConfigItemExpanded
В связи с изменением структуры хранения событий в коллекторе изменилась функция фильтрации и поиска событий -
FilterCollectorEvents
. - Появилась возможность опубликовать КЕ сразу при ее создании как для одной или нескольких РГ, так и для всех РГ сразу — в функциях:
-
Неактуальные функции ⚠️
Функции, работающие непосредственно с выдачей и удалением прав доступа к КЕ, с версии Monq 9 станут неактуальными и перестанут работать. Эти функции будут полностью удалены в старших версиях. На данный момент они останутся для удобства замены их на новые в существующих сценариях автоматизации.
Список неактуальных функций и их замена:
Новая функция Заменяет устаревшие функции CreateConfigItemPublicationBatch
GrantAccessToConfigItem
UpdateAccessToConfigItem
GrantAccessToConfigItemExpanded
UpdateAccessToConfigItemExpanded
DeleteConfigItemPublicationBatch
DeleteAccessToConfigItem
10. Обновленное меню
Знакомство, как и ежедневная работа с системой, начинается с главного меню. В Monq 9 главное меню претерпело весьма ощутимые изменения:
|
Документация: Главное меню
11. Изменения в других разделах
Управление пользователями
В Monq 9 мы обновили интерфейс сервиса «Управление пользователями»:
- Обновили представление списков для вкладок «Пользователи» и «Журнал действий» («История действий» в ранних версиях);
- Заменили фильтры на вкладках «Пользователи» и «Журнал действий» более функциональными рубрикаторами;
- Оптимизировали работу сервиса и исправили баги раздела.
Правила порогов
В карточке правил порогов по метрикам в качестве источников данных теперь доступны потоки только с типом «Метрики» в связи с разделением типов потоков.
Экран сигналов
Для работы с большим количеством активных и архивных сигналов на экране сигналов было увеличено время исполнения запроса с 30 до 60 секунд.
Zabbix Triggers и Zabbix Hosts
В связи с развитием функционала автоматизации и наличием контент-паков для автопостроения РСМ с привязкой алертов из Zabbix к автоматически созданным КЕ в Monq 9 было принято решение отказаться от поддержки специальных интерфейсов для ручной привязки триггеров и узлов Zabbix (волшебная палочка рядом с соответствующими атрибутами в карточке КЕ) к конфигурационным единицам.
Сами атрибуты для хостов и триггеров Zabbix, их значения (даже если они были ранее заполнены через специнтерфейс) и возможность мануального (неавтоматизированного) редактирования остаются без изменений и доступны пользователям в интерфейсе параметров КЕ.
Обслуживание системы (обновление / диагностика неисправностей)
- Для быстрого просмотра количества очередей, подписчиков и сообщений в брокере сообщений RabbitMQ в клиент управления monqctl добавлена специальная команда:
monqctl instance get queues
- команда будет полезна при эксплуатации и поиске проблем - Также добавлена команда для очистки очередей RabbitMQ -
monqctl instance clear queue
- Для предотвращения «падения» RabbitMQ при некорректной работе системы по умолчанию отключен механизм "dead letter", что снижает нагрузку на брокер сообщений
При необходимости для диагностики проблемы "dead letter" можно включить
Переход с версии 8.9.2 на 9.0.0
Автоматизированные миграции данных
Мы позаботились о пользователях Monq 8. В состав пакета обновлений Monq 9 включены специальные миграторы для плавного перехода:
- Для преобразования существующих заданий потоков в сборщики данных;
- Для типизации уже настроенных потоков;
- Для изменения структуры собранных событий и логов в коллекторе;
- Для изменения прав доступа к КЕ на публикации.
Перед обновлением внимательно читайте инструкцию!
Мигратор для создания сборщиков данных из заданий потоков
Мигратор преобразует каждое задание потока в самостоятельный сборщик со следующими параметрами:
- Название сборщиков формируется из названия задания. Если задание имеет неуникальное название в рамках РГ, к нему будет добавлен идентификатор потока;
- Владелец у сборщика совпадает с владельцем потока, которому принадлежало задание;
- Состояние сборщика совпадает с состоянием соответствующего задания;
- Конфигурация запуска сборщиков совпадает с конфигурацией задания.
- Параметры сборщиков полностью копируют параметры, которые были заданы в соответствующем потоке, но также автоматически изменяется обращение к этим параметрам в YAML-скрипте:
- Все использования
$.vars.streams.params.[название параметра]
будут автоматически заменены на$.vars.[название параметра]
; - Все использования
{{ vars.streams.params.[название параметра]}}
будут автоматически заменены на{{ vars.[название параметра]}}
; $.vars.streams.key
,$.vars.streams.id
и$.vars.streams.name
останутся без изменений.
- Все использования
- YAML-скрипт сборщика полностью совпадает со скриптом задания, за исключением обращения к заданным параметрам (см. пункт выше).
Будут безвозвратно удалены из системы без миграции в сборщики (так как все эти проверки выполняются при сборе данных) все задания, использующие следующие плагины:
- Zabbix - Api Connection Check;
- Zabbix - Version Check;
- Scom - Database Connection Check;
- Nagios - Api Connection Check.
Мигратор для потоков данных
Для облегчения процесса разделения потоков на типы по приему данных (Метрики / Логи) была реализована утилита, которая запускается с помощью соответствующей команды (подробнее в инструкции по установке релиза), которая поможет с «переездом» на новую версию. После запуска утилита сформирует список потоков и предположит их типы.
Шаги работы программы:
- Утилита выполняет запрос во все БД и формирует списки потоков, которые записывали данные в ClickHouse или VictoriaMetrics (список потоков, отправлявших события и логи в ClickHouse, метрики в VictoriaMetrics, все потоки, которые есть в системе в PostgreSQL).
- После формирования списков потоков утилита отображает пользователю предположения, к какому типу поток будет относиться. Логика распределения:
ClickHouse | VictoriaMetrics | PostgreSQL | Предполагаемый тип |
---|---|---|---|
Нет записей | Нет записей | Есть запись | ID такого потока и его РГ будут добавлены в колонку «Поток без данных» |
Нет записей | Есть запись | Есть запись | ID такого потока и его РГ будут добавлены в колонку «Метрики» |
Есть запись | Нет записей | Есть запись | ID такого потока и его РГ будут добавлены в колонку «События и логи» |
Есть запись | Есть запись | Есть запись | ID такого потока и его РГ будут добавлены в колонку «Неопределенный тип» |
Пример сформированного списка
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| StreamId | StreamName | WorkGroupId | UserspaceId | EventsAndLogs | Metrics | StreamType | StreamParserType | StreamParserOptions | DataStorage | PostHandle |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 1 | Zabbix Stream | 23 | 1 | True | False | EventsAndLogs | Automaton | - | True | True |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 2 | vCenter Stream | 23 | 1 | True | False | EventsAndLogs | Automaton | - | True | True |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 3 | StreamFullRequestParser | 23 | 1 | True | False | EventsAndLogs | Automaton | - | True | True |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 4 | SCOM | 23 | 1 | True | False | EventsAndLogs | Automaton | - | True | True |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 5 | Prometheus Stream | 23 | 1 | True | False | EventsAndLogs | Automaton | - | True | True |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 6 | Nagios Stream | 23 | 1 | True | False | EventsAndLogs | Automaton | - | True | True |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 7 | Nagios Stream - Остановлен поток | 23 | 1 | True | False | EventsAndLogs | Automaton | - | True | True |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 8 | Nagios Stream - Остановлено задание | 23 | 1 | True | False | EventsAndLogs | Automaton | - | True | True |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 9 | Поток с метриками и с кастомным обраб... | 23 | 1 | True | True | Metrics | Metrics | - | True | False |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Мигратор автоматически конвертирует потоки согласно новым типам. Сам мигратор будет различать потоки так же как и программа для подготовки миграции.
Шаги миграции:
- Всем потокам из столбца «Поток без данных» будет присвоен тип «События и логи»;
- Сценарий обработчика будет полностью соответствовать тому сценарию, который был у потока;
- Политика данных проставляется автоматически — «Хранение и постобработка».
- Всем потокам из столбца «Метрики» будет присвоен тип «Метрики»;
- Для потока проставляется дефолтный встроенный ETL-обработчик без сценария для метрик;
- Политика данных проставляется автоматически — «Хранение данных».
- Всем потокам из столбца «События и логи» будет присвоен тип «События и логи»;
- Сценарий обработчика будет полностью соответствовать тому сценарию, который был у потока;
- Политика данных проставляется автоматически — «Хранение и постобработка».
- ⚠️ Всем потокам из столбца «Неопределенный тип» будет присвоен тип «Метрики»;
- Для потока проставляется дефолтный встроенный ETL-обработчик без сценария для метрик;
- Политика данных проставляется автоматически — «Хранение данных».
- Создаются новые потоки данных с названием потока + Logs, а всем записям событий в ClickHouse таких потоков проставляется ID новых созданных потоков. Таким образом останется возможность просматривать события и метрики после миграции потоков по каждому потоку. Все имеющиеся задания будут преобразованы в сборщики данных и сохранят связь с изначальным потоком, который получит тип метрики. Если какие-то задания собирали события, а не метрики, их нужно будет привязать к новому созданному потоку-клону для логов вручную.
- Сценарий обработчика будет полностью соответствовать тому сценарию, который был у потока;
- Политика данных проставляется автоматически — «Хранение и постобработка».
Мигратор обновления структуры собранных логов в коллекторе
Для ускорения работы с логами (поиск / фильтрация / индексирование) мы изменили структуру хранения текстовых данных (событий и логов) в коллекторе.
Начиная с 9-й версии все данные хранятся в виде «плоского» JSON. Чтобы не потерять уже накопленную информацию, предусмотрен мигратор, который преобразует все данные в коллекторе событий и логов в новый формат.
Мигратор расшарок КЕ
Мигратор автоматически преобразует существующие настройки доступа в новый формат публикаций:
- Мигратор автоматически найдет все связи влияния между КЕ из разных РГ. Те КЕ, которые влияют на объекты других рабочих групп, будут автоматически опубликованы для этих РГ;
- После миграции в системе не останется устаревших правил. Любая КЕ, влияющая на чужую РГ, будет опубликована, а любая опубликованная КЕ будет оказывать такое влияние;
- Все ранее созданные правила предоставления доступа к КЕ для других РГ будут безвозвратно удалены.
Ручные настройки
После обновления системы необходимо выполнить следующие действия:
- Обновить все агенты на последнюю версию — 3.0.
Со старой версией агента Monq 9 работать не будет
- Проверить работоспособность сценариев автоматизации, в которых исполняются функции по изменению прав доступа к КЕ и фильтрации событий потока:
- Функции, содержащие старые модели КЕ (с расшарками), будут изменены и будут содержать модели КЕ с параметрами публикации.
Необходимо будет вручную восстановить сценарии. Если вы не использовали свойстваПосле обновления связи с удаленными пинами пропадут
SharedToWorkGroups
и структурыSharedWorkGroup
,WorkGroupGrantModel
— сценарии будут работать корректно после обновления без дополнительных действий.
Список затрагиваемых функций:CreateConfigItem
CreateConfigItemExpanded
CreateConfigItemsBatch
FilterConfigItemsExtended
GetConfigItem
GetConfigItemsBatch
UpdateConfigItem
UpdateConfigItemExpanded
CreateSubordinationLink
DeleteSubordinationLink
- Пин
query
функцииFilterCollectorEvents
будет изменен под новые возможности строки запроса на экране логов.
После обновления для корректной фильтрации в настроенных сценариях необходимо вручную актуализировать ID потоков, а также адаптировать запрос в пинеquery
под новый синтаксис MQL.- Независимо от того, какие параметры передаст пользователь в Interval, Aggregations теперь будет возвращать пустой список.
- В качестве id, rawId каждый раз будут генерироваться новые GUID.
- Функции, содержащие старые модели КЕ (с расшарками), будут изменены и будут содержать модели КЕ с параметрами публикации.
- Перенастроить мониторинг потоков и выполнения заданий:
- В БП появилось новое стартовое событие «Статус сборщика данных». Данный блок позволит запускать БП при смене статуса сборщика или группы сборщиков в зависимости от настроек префильтра, что позволит оперативно реагировать на проблемы, возникшие при сборе данных.
- Также в БП был добавлен стартовый блок «Мониторинг потока». Опция мониторинга включается на самом потоке и будет отправлять событие в БП, если в поток не поступают данные дольше указанного времени. Работает для всех типов потока.
- Создать новые карты логов вместо фильтров, которые использовались в ранних версиях на экране «События и логи».
Изменение условий лицензирования
В модуль лицензионной защиты Monq 9 был внесен ряд технологических изменений, а также изменена структура лицензионного ключа.
Monq 9 работает только с новой версией лицензионного ключа!Перед выполнением обновления получите новый лицензионный ключ:
- Если вы используете коммерческую версию — обратитесь к вашему персональному менеджеру
- Если вы используете бесплатную версию — отправьте заявку на адрес askformonq@monq.ru