Перейти к основному содержимому

Обновление 8.3.0 (23.09.2024)

Основная информация​

Основные изменения релиза 8.3.0​

  • Добавлена функция группировки КЕ в кластеры на Графе РСМ, что упрощает работу с картами, содержащими большое количество КЕ и делает визуальное отображение системы более понятным
  • Внешние агенты теперь поддерживают прослушивание портов по протоколам TCP и UDP, что расширяет возможности мониторинга сетевых устройств
    • Добавлен плагин для прослушивания Syslog, что позволит собирать системные сообщения
    • Добавлен плагин для приема SNMP-трапов, что позволит оперативно получать уведомления о событиях в сети
  • Оптимизирован фоновый процесс расчета отчетов о доступности КЕ
  • Экран оперативного центра получил новые возможности сортировки списка КЕ и небольшие обновления вкладок Здоровья и Доступа КЕ
  • Появился сервис предиктивной аналитики для порогов, который позволит пользователям проактивно реагировать на будущие изменения метрик, предотвращая возможную деградацию еще до того, как произойдет срабатывание пороговых значений за счет прогнозирования состояний временных рядов с использованием технологий машинного обучения
  • Добавлена визуализация временного ряда в настройках правил порогов, теперь можно видеть графики по метрике прямо при настройке, не пользуясь для этого UI другого ПО
  • Добавлен инструмент, который поможет автоматически задавать уровни для условий создания порога. Он поможет задать стартовые значения для уровней, которые уже можно точно настроить под свои задачи, по нажатию кнопки
  • В переменных запуска для ручного запуска БП добавлена возможность использования нескольких основных системных API структур
  • Изменены названия очередей маршрутных узлов автоматона в RabbitMQ с технических на более читаемые и понятные

Кластеризация Графа РСМ​

  • Для отображение Карт или Фильтров РСМ с большим количеством КЕ была реализована группировка КЕ в кластера и отображение их на холсте (во вкладке Граф) вместо штучных КЕ
  • КЕ объединяются в кластеры по связям влияния на графе Здоровья, только на экране Оперативного центра. Граф в разделе CMDB или граф структуры не имеет отношения к кластеризации
  • Количество кластеров в представлении зависит от:
    • количества корневых КЕ - КЕ, у которых для выбранного фильтра нет направленных от нее связей влияния, но есть связи влияния направленные на нее. Каждая такая КЕ представляет из себя отдельный граф, который и будет представлен в виде отдельного кластера. В кластер попадают все КЕ карты оказывающие влияние на корневую
    • наличия атомарных КЕ - КЕ без связей влияния. Все такие КЕ собраны в единый кластер "КЕ без связей"
    • наличия последних КЕ в цепочке связей - КЕ, которые влияют на корневую КЕ на текущем уровне и являются последними в цепочке, т.е на них не оказывают влияние другие КЕ (такой кластер бывает только на втором и ниже уровне, при первом открытии графа, таких кластеров нет). Все такие КЕ собраны в кластер "Независимые КЕ"
  • Кластеризацию графа можно включать и выключать, а так же настроить порог КЕ, при превышении которого КЕ будут группироваться в кластеры. Данная настройка есть на графе здоровья, а так же в настройках персонализации экрана оперативного центра
  • При открытии графа с кластерами, пользователю будет отображаться первый уровень графа, на котором видны все вершины Карты РСМ. Пользователь сможет путешествовать по графу проваливаясь в нужный кластер. После перехода в кластер с корневой КЕ, в центре графа будет отображаться корневая КЕ открытого кластера, а вокруг нее построятся другие кластеры или КЕ, наглядно отображая влияние других объектов карты на корневую КЕ на текущем уровне графа. Пользователь может погрузиться на любую глубину графа и если оставшееся кол-во КЕ на графе станет меньше установленного порога, граф будет отображать эти КЕ в привычном виде без группировки
  • Список КЕ и сам граф имеет хлебные крошки, если пользователю необходимо вернуться на один или несколько уровней назад
  • Список КЕ синхронизирован с графом кластеров, т.е КЕ в списке фильтруются при путешествии по графу. В списке остаются лишь те КЕ, к которым можно добраться с текущего уровня графа
  • При выборе КЕ в списке, кластеры содержащие выбранную КЕ будут иметь соответствующую подсветку и наоборот, если пользователь выберет кластер или кластеры на графе, в списке будут выбраны все КЕ, которые находятся внутри выбранных кластеров
  • При выборе КЕ в списке, которая оказывает влияние сразу на несколько кластеров (на более глубоком уровне), между задействованными кластерами появятся ненаправленные связи, наглядно отображающие связь между текущими кластерами т.к они имеют общую КЕ на глубине. Если выбрать такую связь, в списке выберутся все общие КЕ, которые находятся в двух связанных кластерах
  • Кластер с корневой КЕ отображает следующую информацию: название корневой КЕ, здоровье и статус корневой КЕ, иконку Типа корневой КЕ, кол-во КЕ в кластере, а так же цветную диаграмму статусов КЕ внутри кластера. Вся эта информация (кроме кол-ва КЕ в кластере) обновляется по вебсокетам
  • Кластеры имеют свое контекстное меню позволяющее выполнять массовые действия со всеми КЕ в кластере, а так же выполнить привычные действия с корневой КЕ кластера (только для кластеров с корневой КЕ)
  • Для Графа РСМ задано строгое ограничение на кол-во отображаемых КЕ, если КЕ на карте более 11 000, пользователю будет отображаться предупреждение с просьбой сузить кол-во КЕ фильтром CMDB

Агенты​

  • Внешние агенты теперь поддерживают прослушивание портов по протоколам TCP и UDP. Это нововведение значительно расширяет возможности мониторинга сетевых устройств, обеспечивая дополнительный контроль над сетевыми операциями:
    • Сбор системных сообщений - осуществляется плагином Syslog
    • Получение уведомлений о событиях в сети - осуществляется плагином Snmp-trap
  • Данный функционал доступен только в новой версии агента, однако благодаря обратной совместимости, агенты предыдущих версий подключатся к Monq 8.3.0 без проблем, а новый агент будет работать с более старыми версиями, что не обязывает поднимать версию всех существующих агентов для корректного выполнения существующих заданий в потоках
  • Процесс прослушивания портов является непрерывным (пока агент не будет остановлен) и начинает работу при запуске агента. Настройки для прослушивания порта указываются в рабочей конфигурации агента, которая размещается локально на хосте с агентом. Рабочая конфигурация выступает в роли непрерывного задания для агента и представляет из себя файл с YAML скриптом, написанным по аналогии с зданиями потока. Путь к рабочим конфигурация указывается в конфиге подключения агента
  • Каждый выполняемый рабочий конфиг будет занимать один слот агента. Можно использовать один рабочий конфиг для прослушивания сразу нескольких портов (используя несколько job-ов), однако при возникновении ошибки в работе по одному из портов, конфиг будет остановлен и прослушивание оставшихся портов прекратиться, по этому рекомендуется использовать один рабочий конфиг для прослушивания одного порта
  • Общие настройки агента для прослушивания портов указываются в конфигурационном файле подключения, а само прослушивание осуществляется агентом с использованием плагинов

Плагины TCP и UDP​

Плагины tcp и udp осуществляют прослушивание указанного порта и передают собранные данные в коллектор в формате JSON. Если сообщения полученные с порта были отправлены не в формате JSON, полученный лог будет дополнительно обработан и приведен к виду { "data": "<запись из порта>" }

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

Плагин syslog​

Плагин syslog осуществляет сбор системных сообщений с указанного порта, автоматически преобразует полученные сообщения (пользователь сам указывает какой парсер использовать) и передает их в коллектор в формате JSON

  • Вызов плагина указывается в поле plugin в рабочей конфигурации
  • Для корректной работы агента плагин syslog должен находится в директории указанной в коннект конфиге
  • Параметры конфигурации плагина указываются в YAML скрипте рабочей конфигурации агента

Плагин snmp-trap​

Плагин snmp-trap осуществляет сбор SNMP трапов с порта и умеет самостоятельно декодировать данные с применением MIB файлов. Нужные файлы необходимо разместить в директории на хосте где установлен агент и указать к ним путь, после чего плагин будет декодировать полученные трапы и отправлять их в коллектор в формате JSON.

Плагин поддерживает работу с трапами версий: SNMPv1 и SNMPv2

  • Вызов плагина указывается в поле plugin в рабочей конфигурации
  • Для корректной работы агента плагин snmp-trap должен находится в директории указанной в коннект конфиге, вместе с остальными плагинами
  • Параметры конфигурации плагина указываются в YAML скрипте рабочей конфигурации агента:

Автопоставка плагинов на агент​

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

Плагины попадут в хранилище автоматически при установке текущей версии Монк с использованием утилиты управления сервисами Monq - monqctl.

Список плагинов доступных для автозагрузки:

  • zabbixCheckConnection
  • zabbixEventsDataFlow
  • zabbixCheckVersion
  • scomCheckConnection
  • scomEventsDataFlow
  • vmwareEventsDataFlow
  • vmwareTopologySync
  • nagiosCheckConnection
  • nagiosEventsDataFlow
  • k8sMetricsDataFlow
  • k8sTopologySync
  • metricsFromStaticTargets
  • postgresqlPlugin
  • syslog
  • snmpTrap

Автопоставка плагинов на агент регулируется в конфиге подключения агента в секции [Plugins] параметром Autoload.

В текущей версии Monq автопоставки версии плагинов не учитываются, т.е если агент имеет в указанной директории плагин версии 1.0.0, а в хранилище уже имеется этот же плагин версии 1.1.0, он не будет скачан т.к агент будет считать, что у него есть всё необходимое для выполнения задания / конфига.

  • Изменен механизм работы внутреннего агента с плагинами. После установки новой версии Monq хранилище внутреннего агента будет очищено, а необходимые плагины появятся автоматически при выполнении задания требующего такой плагин. Если ранее внутренний агент содержал кастомные плагины их нужно будет загрузить в хранилище на диспетчер заданий. Добавить кастомные плагины в хранилище можно так же с использованием соответствующей команды через monqctl.

Оперативный центр​

  • Появился поиск по РГ при предоставлении доступа для КЕ во вкладке Доступ на экране Оперативного центра и в карточке КЕ CMDB. Интерфейс вкладки доступ так же был обновлен
  • Изменилось поведение вкладок правой группы, теперь данные вкладки доступны всегда, но по прежнему отображают информацию только при выборе одной КЕ в списке
  • При попадании на вкладку Здоровье, на экране Оперативного центра, с графа РСМ, путем "проваливания" в КЕ появилась возможность вернуться обратно на граф
  • Если здоровье КЕ находится в диапазоне от 99,1% до 99,9% её отображаемое здоровье в списке КЕ будет округлено до 99%, что б явно показать, что КЕ не здорова на 100%
  • Появилась возможность сортировки КЕ в списке на экране Оперативного центра и в таблице CMDB по здоровью КЕ
  • Сортировка КЕ по статусу в списке КЕ на экране Оперативного центра и в таблице CMDB, теперь дополнительно сортирует КЕ одинаковых статусов по здоровью
  • Фильтр CMDB теперь можно сохранить только как Карту РСМ. Нельзя применить фильтрацию не в пределах существующей Карты РСМ
  • Часть массовых действий с КЕ в списке на экране Оперативного центра была временно скрыта. Массовые действия с КЕ в таблице CMDB остались без изменений

Настройки CMDB​

  • Появилась возможность указывать дробные числа при настройке статусной модели для Типа КЕ

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

  • Добавлена возможность ручного запуска БП из карточки сигнала (3 точки)

  • Добавлена возможность ручного запуска БП из КЕ в контекстном меню с холста графов

  • Добавлена возможность ручного запуска БП из карточки БП (холста БП)

  • Новые типы данных для переменных запуска — внутренние структуры:

    • ConnectionsStructApi
    • RecipientsListStructApi
    • UsersStructApi

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

Автоматон​

  • Изменение названия очередей маршрутных узлов автоматона в RabbitMQ. Данное изменение производится с помощью специальной миграции.

    В случае проблем с миграцией рекомендуется увеличить количество памяти доступное для RabbitMQ

    • <env>_pl_automaton_bpnoderunprocessor_<id> - маршрутный узел для бизнес процессов
    • <env>_pl_automaton_buildsprocessor_<id> - маршрутный узел сборок
    • <env>_pl_automaton_cmdbautodiscovery_<id> - маршрутный узел автопостроения РСМ
    • <env>_pl_automaton_signals_processor_<id>- маршрутный узел сигналов
    • <env>_pl_automaton_stream_raw_events_processor_<id>- маршрутный узел обработчика первичных событий
    • <env>_pl_automaton_thresholdsprocessor_<id>- маршрутный узел порогов

  • Модель события порогов для OnThresholdForecastEvent и OnProcessedThresholdEvent расширена, теперь в ней присутствует параметр Forecast с информацией по прогнозированию для порога

  • Обновление функции HTTPRequest, в нее добавлен пин JsonSerializationSettings, который отвечает за настройки сериализации и десериализации ключей тела ответа/запроса

    В старых сценариях эта настройка будет включена для всех блоков функции автоматически, для новых блоков ее нужно будет включать самостоятельно

  • При работе со сценариями автоматизации теперь есть возможность создания локальных структур при помощи JSON

    Требуется только загрузить нужный JSON и структуры с нужными типами ключей создадутся сами

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

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

    Инструмент расставляет условия опираясь на метрики за последние 7 дней

  • В строке запроса метрик появился автодополнение ввода по всем названиям метрик находящимся в БД

    В этой же строке есть возможность по кнопке раскрыть полный список всех доступных метрик

  • Добавились графики для временных рядов. На их отображение влияет только сам запрос, окно вычисления при запросе вычисляется автоматически для формирования более информативного графика
    • Для идентификации отображения графиков временных рядов была добавлена легенда. В легенде отображаются не более 10 метрик по запросу, если их больше, то эта информация будет содержаться в счетчике
    • Каждый график имеет индивидуальный цвет
    • При нажатии на метрику она будет скрыта на графике
    • При нажатии на метку у метрики она будет скопирована в буфер обмена
    • На графике будут отображаться заданные уровни создания порогов
  • На странице управления порогов добавились:
    • Фильтры по статусам и потокам для поиска правил порогов
    • Поля по которым осуществляется поиск в поисковой строке:
      • Запрос
      • Название порога
      • Аннотации (оба поля)

Прогнозирование​

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

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

  • Для включения сервиса прогнозирования требуется раскрыть дополнительные настройки в разделе "Запрос метрик" в настройках правил порогов и активировать его

  • На прогнозирование влияют такие настройки как

    • Окно вычислений
    • Настройки в разделе прогнозирования

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

    • Сезонный

      Изображение

      При построении сезонного прогноза и обучении модель это делает на имеющихся данных по метрике по формуле: выбранный сезон прогнозирования * 3

    • Линейный

      Изображение

  • Расчет прогноза запускается в случаях:

    • При включенной опции прогнозирования
      • Запуска расчета правил порогов
      • Изменения уровня открытого порога
      • Перерасчета правила порога по времени (зависит от параметра "Частота расчета")
      • При изменении настроек прогнозирования
    • Если правило порогов запущено с выключенным прогнозированием и опция прогнозирования будет включена

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

    • Модель прогнозирования обучается при:
      • первом запуске прогнозирования для порога
      • когда процент ошибки предсказаний временных рядов превышает 5%
    • Для обучения модели требуется минимум три значения, которые вернутся после отработки окна вычисления

      Например, если ваш временной ряд содержит лишь метрики за 3ч, то максимальное значение окна вычисления должно быть не больше 1ч

  • Прогноз может быть двух видов

    • С сохранением уровня порога
      • На весь период прогнозирования порог останется на том же уровне (крайнее прогнозное значение остается на том же уровне)
    • С изменением уровня порога
      • Предполагается, что порог в течении прогнозируемого периода изменит свой уровень
      • Прогнозное значение для такого прогноза высчитывается по этапам:
        • Вычисляется крайняя прогнозируемая точка по заданным настройкам прогнозирования
        • Ищется первое пересечение прогнозируемого временного ряда с уровнем в котором находится прогнозируемая крайняя точка
          • Если крайняя прогнозируемая точка остается на том же уровне, то пересечение не ищется (сохранение уровня порога)
        • Полученная точка является прогнозом

        Например: сейчас порог на уровне ОК, прогноз построен на 3 дня и на графике отображается, что через 3 дня крайняя прогнозная точка будет на уровне Major. Но прогнозируемый временной ряд пересечет уровень Major раньше — через 2.5 дня, еще не оказавшись в крайней прогнозируемой точке, поэтому это и будет нашим прогнозным значением

  • Полученный прогноз можно увидеть:

    • На графике в правиле порога
      • Отображается в виде графика
    • В оперативном центре во вкладке порогов

      Требуется включить столбец прогнозов в разделе персонализации

    • Прогноз будет отображен в виде блочков с информацией по прогнозу

  • Прогнозы можно использовать в автоматизации, для этого в сценарии добавлено новое событие запуска сценариев типа SignalsProcessor — "OnThresholdForecastEvent"

    • В него приходят события после расчета прогноза для порогов (когда срабатывает расчета описано выше)
    • Информация о прогнозе и прошлом прогнозном значении будет храниться в ключе Forecast
      • При первом прогнозировании для порога прошлое значение будет равно 0

  • Если отключить прогнозирование для открытого порога, то прогнозное значение для него пропадет

  • Прогнозное значение остается храниться для закрытого порога, если на момент его закрытия сервис прогнозирования для него работал

Оптимизации​

  • Оптимизирована обработка событий изменения КЕ на узле live_fm_projects_api_service, что позволило ускорить разбор этой очереди в RabbitMQ
  • Оптимизирован фоновый процесс по расчету отчетов о доступности КЕ
  • Ускорение работы фильтрации в оперативном центре во вкладках сигналы, пороги, журнал и обслуживание в 2.5 раза

Работа над ошибками​

Оперативный центр​

  • Исправлены настройки представления пользователя, в дефолтной настройке отсутствовал столбец "Стадия ЖЦ" на экране Оперативного центра
  • Исправлен баг с отсутствием некоторых КЕ при использовании окна поиска при создании связи влияния, подчинения или сигнала на графе экрана Оперативного центра
  • Исправлен баг, при создании связи влияния, окно создания связи отображалось за пределами экрана на вкладке граф экрана Оперативного центра
  • Исправлен баг с отсутствием обновления информации по связям подчинения на графе структура экрана Оперативного центра
  • Исправлен баг, при переходе в новую вкладку браузера через контекстное меню, КЕ не была выбрана и вкладки правой группы не отображали информацию
  • Исправлен баг из-за которого график метрического ряда соединял разрывы в таймлайне порога на вкладке порогов

Потоки данных​

  • Исправлен баг, при добавлении в поток задания с двумя job'ами после выполнения отправлялся только один артефакт
  • Исправлен баг с отсутствием возможности взаимодействовать с объектами массива полученными в артефакте
  • Скорректировано подсветка поля РГ-Владельца при изменении, если название не уникально в рамках нового владельца, в карточке потока

Отчеты​

  • Скорректировано отображение меток сервисных режимов в файле экспорта отчета
  • Скорректировано отображение Архивных КЕ при добавлении КЕ для формирования Отчета
  • Исправлен баг, при экспорте отчета вместо времени формирования отчета отображалось время экспорта отчета
  • Исправлен баг с отображением веса шаблонов в настройках мульти-отчета, после обновления страницы
  • Исправлен баг с отображением последнего сгенерированного отчета о доступности КЕ после удаления всех отчетов шаблона
  • Исправлен баг с отсутствием кнопки сохранения шаблона при изменении его названия

Пороги​

  • Исправили отображение иконок у потоков данных в настройках правил создания порогов
  • Исправили отображение расположения иконки с инициалами владельца правила порога в настройках их создания

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

  • Скорректирована работа удаления материализованных представлений при обновлении кластерной версии Monq из-за чего не отображалась история запусков БП
  • Исправлен баг при котором блоки следующие за Wait выделялись в отдельный запуск в истории запусков БП
  • Исправлен баг, когда при удалении элемента массива в входных параметрах не появлялась кнопка для сохранения изменений
  • Исправлен баг с валидацией значений в наборе значений переменной запуска
  • Исправлен баг с переходом курсора в конец поля ввода при настройке переменных запуска

Другое​

  • Исправлен баг возникавший при использовании публичной API пакетного частичного обновления КЕ. При отправке запроса на пакетное частичное обновление информации о КЕ поменяв ID в запросе на свой, сбрасывались метки КЕ, удалялось описание и тип КЕ менялся на Default
  • Исправлен баг, в меню создания связи на Графе РСМ при поиске КЕ отображались не все КЕ
  • Скорректировано поведение API получения КЕ по уникальным ключевым Атрибутам: если КЕ не найдена отдается соответствующее сообщение вместо ошибки.