Добрый вечер! А мы не с пустыми руками к Вам в гости 😀.
Вышел небольшой релиз 4.3.9. В нем мы постарались учесть пользовательский опыт и скорректировать ряд алгоритмов, а также исправить ряд досадных багов.
🔸Изменили логику автоматического создания синтетического триггера по шаблону из триггера Zabbix.
Ранее синтетический триггер создавался только в момент первого прихода события из Zabbix. Это доставляло определенные неудобства при настройке правил и действий. Теперь синтетический триггер по шаблону "systemZabbixTrigger" создается сразу же. Для остальных шаблонов логика работы осталась прежней.
🔸В дополнение к функционалу по управлению сервисными режимами КЕ через API, выпущенному в версии 4.3.8, добавили алгоритм, который позволяет учитывать изменения в графе РСМ при назначении сервисного режима параметрически. Сервис установки режимов обслуживания подписывается на информацию об обновлении графа РСМ: добавление новых подчиненных КЕ, изменениях связей подчинения. И учитывает эти изменения: добавляет/удаляет также как это было бы в случае прямого изменения пользователем. Теперь вы можете не беспокоится, что при изменении ресурсно-сервисной модели у вас пропадет назначенный сервисный режим для каких-либо КЕ.
🔸Выпущен ряд оптимизаций 🏎:
🔺Изменен алгоритм кэширования сборок функциональных тестов из-за переполнения памяти на Redis сервере. Это изменение освободит дополнительную память под другие данные для кэширования.
🔺Обновлен механизм взаимодействия микросервисов с Kubernetes. Это второй пакет изменений, который позволит в будущем полностью автоматизировать обновление нашего продукта, что должно привести к радикальному уменьшению времени обновления.
🔸Решены следующие баги, возникшие в 4.3.8. Наши тестировщики просят "понять и простить" 🥺
🔺Некорректная работа сервисного режима, сгенерированного по ЗНИ из HP Service Manager, после обновления 4.3.8.
🔺Сервисный режим заданный по API в статусе "InProgress" не учитывается при обработке событий правилами с проверкой на сервисный режим. События их успешно проходят, действия выполняются.
🔺Объекты в макросах не преобразуются в текст, а выводятся в JSON.
Вышел небольшой релиз 4.3.9. В нем мы постарались учесть пользовательский опыт и скорректировать ряд алгоритмов, а также исправить ряд досадных багов.
🔸Изменили логику автоматического создания синтетического триггера по шаблону из триггера Zabbix.
Ранее синтетический триггер создавался только в момент первого прихода события из Zabbix. Это доставляло определенные неудобства при настройке правил и действий. Теперь синтетический триггер по шаблону "systemZabbixTrigger" создается сразу же. Для остальных шаблонов логика работы осталась прежней.
🔸В дополнение к функционалу по управлению сервисными режимами КЕ через API, выпущенному в версии 4.3.8, добавили алгоритм, который позволяет учитывать изменения в графе РСМ при назначении сервисного режима параметрически. Сервис установки режимов обслуживания подписывается на информацию об обновлении графа РСМ: добавление новых подчиненных КЕ, изменениях связей подчинения. И учитывает эти изменения: добавляет/удаляет также как это было бы в случае прямого изменения пользователем. Теперь вы можете не беспокоится, что при изменении ресурсно-сервисной модели у вас пропадет назначенный сервисный режим для каких-либо КЕ.
🔸Выпущен ряд оптимизаций 🏎:
🔺Изменен алгоритм кэширования сборок функциональных тестов из-за переполнения памяти на Redis сервере. Это изменение освободит дополнительную память под другие данные для кэширования.
🔺Обновлен механизм взаимодействия микросервисов с Kubernetes. Это второй пакет изменений, который позволит в будущем полностью автоматизировать обновление нашего продукта, что должно привести к радикальному уменьшению времени обновления.
🔸Решены следующие баги, возникшие в 4.3.8. Наши тестировщики просят "понять и простить" 🥺
🔺Некорректная работа сервисного режима, сгенерированного по ЗНИ из HP Service Manager, после обновления 4.3.8.
🔺Сервисный режим заданный по API в статусе "InProgress" не учитывается при обработке событий правилами с проверкой на сервисный режим. События их успешно проходят, действия выполняются.
🔺Объекты в макросах не преобразуются в текст, а выводятся в JSON.
Добрый вечер! У нас важное и интересное событие: выход 5й версии нашего продукта MONQ (прежнее название Сервис-Монитор) 🥳🥳🥳.
5-я версия серьезно расширяет наши возможности и позволяет обрабатывать и хранить любые данные на входе, в том числе и неструктурированные логи. Нашу платформу теперь можно использовать не только для событий систем мониторинга ИТ, но ВООБЩЕ ДЛЯ ЛЮБЫХ СОБЫТИЙ (например, для событий безопасности) А расширенные возможности синтетических триггеров позволят вам объединить в одной проблеме события из инфраструктурного мониторинга, систем ИТ-безопасности и синтетических тестов. Наши возможности были оценены в том числе и на конкурсе Skolkovo Cybersecurity Сhallenge (2-е место) и в основном конкурсе технологических стартапов Startup Village 2020, заняв 2 место в треке “Индустриальные технологии" 😎🤓.
5-я версия серьезно расширяет наши возможности и позволяет обрабатывать и хранить любые данные на входе, в том числе и неструктурированные логи. Нашу платформу теперь можно использовать не только для событий систем мониторинга ИТ, но ВООБЩЕ ДЛЯ ЛЮБЫХ СОБЫТИЙ (например, для событий безопасности) А расширенные возможности синтетических триггеров позволят вам объединить в одной проблеме события из инфраструктурного мониторинга, систем ИТ-безопасности и синтетических тестов. Наши возможности были оценены в том числе и на конкурсе Skolkovo Cybersecurity Сhallenge (2-е место) и в основном конкурсе технологических стартапов Startup Village 2020, заняв 2 место в треке “Индустриальные технологии" 😎🤓.
Итак, что же принципиально нового в 5.0:
🔸Новый компонент платформы MONQ Collector (заменил коннекторы к системам мониторинга). Важным преимуществом сборщика данных является возможность обработки сырых данных и превращения их в JSON. Подключить новую систему мониторинга или любой другой источник данных на вход платформы может теперь и обычный инженер отдела эксплуатации, что значительно упрощает внедрение и затраты при подключении новых источников.
MONQ Collector состоит из следующих функциональных блоков:
1. Приемник потоков данных
Это максимально легковесная программа - точка прослушивания HTTP. Программа обёртывает базовую информацию в модель (_id, _aggregatedAt, _connector, _sourceType, _source), и отправляет сообщение в препроцессор на обработку. Программа также проводит валидацию ключа коннектора, а также валидацию входной модели в зависимости от типа входных данных (если формат JSON - то валидность JSON в целом, если это XML, то валидность XML в целом (без схемы)).
2. Препроцессор событий
Препроцессор запускает обработчик входного сообщения, если он есть. Обработчик при этом, может:
▫️выполнять парсинг и превращение текста в JSON;
▫️выполнять обработку пакетных событий - выделять из этих событий единичные элементы. Фактически это парсинг, например события от Prometheus приходят в полу-batch формате;
▫️выполнять преобразование входной модели. Например, добавлять вычисляемое поле или менять тип поля в модели
▫️добавлять кастомные метки для событий.
3. Анализатор схемы БД сообщения
Анализатор формирует модель для базы данных, согласно схемы, записанной в коннекторе, создает эту схему исходя из модели JSON или добавляет нужные поля. Выполняет валидацию данных, согласно схеме. Если находит несоответствия в типах полей - отражает в логах.
🔸Новый компонент платформы MONQ Collector (заменил коннекторы к системам мониторинга). Важным преимуществом сборщика данных является возможность обработки сырых данных и превращения их в JSON. Подключить новую систему мониторинга или любой другой источник данных на вход платформы может теперь и обычный инженер отдела эксплуатации, что значительно упрощает внедрение и затраты при подключении новых источников.
MONQ Collector состоит из следующих функциональных блоков:
1. Приемник потоков данных
Это максимально легковесная программа - точка прослушивания HTTP. Программа обёртывает базовую информацию в модель (_id, _aggregatedAt, _connector, _sourceType, _source), и отправляет сообщение в препроцессор на обработку. Программа также проводит валидацию ключа коннектора, а также валидацию входной модели в зависимости от типа входных данных (если формат JSON - то валидность JSON в целом, если это XML, то валидность XML в целом (без схемы)).
2. Препроцессор событий
Препроцессор запускает обработчик входного сообщения, если он есть. Обработчик при этом, может:
▫️выполнять парсинг и превращение текста в JSON;
▫️выполнять обработку пакетных событий - выделять из этих событий единичные элементы. Фактически это парсинг, например события от Prometheus приходят в полу-batch формате;
▫️выполнять преобразование входной модели. Например, добавлять вычисляемое поле или менять тип поля в модели
▫️добавлять кастомные метки для событий.
3. Анализатор схемы БД сообщения
Анализатор формирует модель для базы данных, согласно схемы, записанной в коннекторе, создает эту схему исходя из модели JSON или добавляет нужные поля. Выполняет валидацию данных, согласно схеме. Если находит несоответствия в типах полей - отражает в логах.
🔸Добавили новый экран по работе с первичными событиями (скриншоты ниже) Раз мы научились работать с любыми логами, данный экран должен был позволить нашим пользователям анализировать и работать с принимаемыми логами. В текущей версии пользователь сможет работать с первичными событиями ВСЕХ потоков, доступных его рабочей группе (а не только по одному индексу, как это сделано в ряде конкурирующих решений). Для этого предоставлен достаточно широкий набор инструментов:
▫️Таблица первичных событий;
▫️Визуализация количества событий за период;
▫️Детальный просмотр событий;
▫️Автообновление событий посредством протокола WebSocket
▫️Строки поиска - используется всем знакомый по продукту Elastic Search синтаксис полнотекстового поиска Lucene.
▫️Таблица первичных событий;
▫️Визуализация количества событий за период;
▫️Детальный просмотр событий;
▫️Автообновление событий посредством протокола WebSocket
▫️Строки поиска - используется всем знакомый по продукту Elastic Search синтаксис полнотекстового поиска Lucene.
🔸Новый функционал в модуле правила и действия. Теперь можно настраивать не только действия по открытию/закрытию проблемы, но и при ее подтверждении.
🔺Пользователь может в настройках указать опцию выполнения операции по подтверждению проблемы. Эта опция доступна для всех операций за исключением “Закрытия инцидента в HPSM”.
Подтверждение статуса синтетического триггера вызывает проверку правил по уже открытым по данному синтетическим триггерам проблемам. В случае успешного прохождения правила запускаются связанные с этим правилом операции, у которых стоит отметка “Подтверждение события”.
Выполненные операции “Подтверждение события” выводятся в подробной информации в виджете “События за период” во вкладке “Действия”.
🔺Унификация шаблонов сообщений
В конструкторе сообщений убран функционал разделения шаблона на начало и конец. Обновление затрагивает все операции.Произведена миграция исторических настроек для операций, которые запускаются как по началу, так и по окончанию проблем, и при этом имеют разные шаблоны на начало и конец.Такие операции преобразованы в две операции. Одна на начало спроблемы с соответствующим шаблоном, а вторая на конец проблемы. Настройки времени активности сохранены.
🔺Добавление опций в запуск скриптов
В операцию “Запуск скрипта” добавлены опции запуска как по подтверждению, так и по завершению проблемы.
🔺Пользователь может в настройках указать опцию выполнения операции по подтверждению проблемы. Эта опция доступна для всех операций за исключением “Закрытия инцидента в HPSM”.
Подтверждение статуса синтетического триггера вызывает проверку правил по уже открытым по данному синтетическим триггерам проблемам. В случае успешного прохождения правила запускаются связанные с этим правилом операции, у которых стоит отметка “Подтверждение события”.
Выполненные операции “Подтверждение события” выводятся в подробной информации в виджете “События за период” во вкладке “Действия”.
🔺Унификация шаблонов сообщений
В конструкторе сообщений убран функционал разделения шаблона на начало и конец. Обновление затрагивает все операции.Произведена миграция исторических настроек для операций, которые запускаются как по началу, так и по окончанию проблем, и при этом имеют разные шаблоны на начало и конец.Такие операции преобразованы в две операции. Одна на начало спроблемы с соответствующим шаблоном, а вторая на конец проблемы. Настройки времени активности сохранены.
🔺Добавление опций в запуск скриптов
В операцию “Запуск скрипта” добавлены опции запуска как по подтверждению, так и по завершению проблемы.
🔸Переработана административная панель.
🔺Появилась возможность писать свои плагины. Пока только для оповещений, в дальнейшем этот функционал будет расширен и на другие части продукта.
🔺Управление библиотеками для написания скриптов. Добавление своих библиотек позволяет серьезно расширит возможности работы с модулей Автоматон.
🔺Появилась возможность писать свои плагины. Пока только для оповещений, в дальнейшем этот функционал будет расширен и на другие части продукта.
🔺Управление библиотеками для написания скриптов. Добавление своих библиотек позволяет серьезно расширит возможности работы с модулей Автоматон.
🏎 Но мы не останавливаемся и в ближайшее время готовим уже следующий пакет нового функционала и плюшек 🥐.
Доброе утро!
Первый месяц лета у нас проходит под знаком РСМ (ресурсно-сервисной модели). Проводим глубокой рефакторинг, добавляем новые функции, переводим на новый графический движок. За июнь мы выпустили два релиза 5.1 (альфа-версия новой РСМ) и 5.2. И вам стали доступны:
Первый месяц лета у нас проходит под знаком РСМ (ресурсно-сервисной модели). Проводим глубокой рефакторинг, добавляем новые функции, переводим на новый графический движок. За июнь мы выпустили два релиза 5.1 (альфа-версия новой РСМ) и 5.2. И вам стали доступны:
🔹Сервис "Карта здоровья конфигурационной единицы (элемент РСМ)".
Основная идея: дать пользователям синтетический параметр для быстрой оценки состояния своих объектов и взаимного влияния объектов друг на друга.
Здоровье объекта рассчитывается на основании здоровья влияющих на него объектов, а также связанных с ним событий мониторинга. Встроенную модель расчета можно легко изменять. Для этого используется два инструмента: 1) вес связи; 2) критический фактор. Вес связи применяется при оценке "равнозначного" влияния, в то время как критический фактор - это прямое наследование здоровья, подходит для критически важных узлов. Для расчета здоровья мы проводим два расчета: один по весу, второй по критическому фактору, результат - наименьшее из двух расчетов.
Давайте разберем на примере: Дан кластер, состоящий из 5 объектов. 1й- объект является мастером и если он упал, то не важно, что будет с остальными, кластер -будет неработоспособным. Остальные объекты являются дополнительными нодами. Ставим всем пяти объектам вес равный 1, но мастеру проставляем еще критический фактор. Согласно модели, если упадет мастер или на нем произойдет деградация, состояние кластера не будет лучше чем у мастера. Если упадет одна из нод, то здоровье кластера будет 80%. Таким образом, модель в целом отвечает картине, которую мы наблюдаем в жизни и можем быстро оценить состояние всего ИТ-окружения в целом.
Хотелось бы отметить, что в процессе работы над сервисом была решена сложная задача мгновенного пересчета здоровья состояние всего графа с учетом изменений вносимых пользователями в модель "на лету".
Основная идея: дать пользователям синтетический параметр для быстрой оценки состояния своих объектов и взаимного влияния объектов друг на друга.
Здоровье объекта рассчитывается на основании здоровья влияющих на него объектов, а также связанных с ним событий мониторинга. Встроенную модель расчета можно легко изменять. Для этого используется два инструмента: 1) вес связи; 2) критический фактор. Вес связи применяется при оценке "равнозначного" влияния, в то время как критический фактор - это прямое наследование здоровья, подходит для критически важных узлов. Для расчета здоровья мы проводим два расчета: один по весу, второй по критическому фактору, результат - наименьшее из двух расчетов.
Давайте разберем на примере: Дан кластер, состоящий из 5 объектов. 1й- объект является мастером и если он упал, то не важно, что будет с остальными, кластер -будет неработоспособным. Остальные объекты являются дополнительными нодами. Ставим всем пяти объектам вес равный 1, но мастеру проставляем еще критический фактор. Согласно модели, если упадет мастер или на нем произойдет деградация, состояние кластера не будет лучше чем у мастера. Если упадет одна из нод, то здоровье кластера будет 80%. Таким образом, модель в целом отвечает картине, которую мы наблюдаем в жизни и можем быстро оценить состояние всего ИТ-окружения в целом.
Хотелось бы отметить, что в процессе работы над сервисом была решена сложная задача мгновенного пересчета здоровья состояние всего графа с учетом изменений вносимых пользователями в модель "на лету".
🔹Новая ресурсно-сервисная модель, объединенная с карточкой конфигурационной единицы (КЕ).
В карточке появилась вкладка расчета здоровья КЕ. Значительно помогает в "root cause" анализе. Можно подробно посмотреть какие факторы наиболее негативно влияют на исследуемый объект, "провалиться" в них, пройти по всей цепочке. В ближайшие релизы в новую карточку перейдет вся информация, которая сейчас доступна в старом интерфейсе системы. Надеемся, это сделает вашу работу с модулем РСМ более полезным и в то же время удобным.
В карточке появилась вкладка расчета здоровья КЕ. Значительно помогает в "root cause" анализе. Можно подробно посмотреть какие факторы наиболее негативно влияют на исследуемый объект, "провалиться" в них, пройти по всей цепочке. В ближайшие релизы в новую карточку перейдет вся информация, которая сейчас доступна в старом интерфейсе системы. Надеемся, это сделает вашу работу с модулем РСМ более полезным и в то же время удобным.