Приветствуем всех!

Вначале хотим принести свои извинения за долгое молчание. Просто...у нас в конце прошлого года "случилась" 4-я версия нашего продукта, и мы окунулись с головой в ее выпуск, доработки связанные с производительностью и восстановлением legacy-функционала. Если говорить про цифры: в строй было введено 18 новых микросервисов, выведено из эксплуатации 8 микросервисов, более 20 сервисов были существенно обновлены. Итого в 3й версии насчитывался 41 микросервис, а уже в 4й их стало 51.

Но мы вернулись, и в этот раз обещаем, что надолго ♾! Еще раз спасибо, что не отписались от нашего канала!

❗️А теперь собственно новость: 13.04.2020 вышел релиз 4.3.8.

🔸 Изменилась работа с макросами в конструкторе сообщения в разделе “Правила и действия”. Теперь существенно расширился набор информации, которую вы сможете отправлять по событиям в системе.

🔺В конструкторе сообщений (конвертик), который доступен при настройке действий для операций с типом “Оповещение”, “Регистрация инцидента в HPSM” и “Закрыть инцидент в HPSM” пользователь теперь имеет возможность добавить макросы в текст сообщения по следующим объектам:
▪️Первичное событие из системы мониторинга - plEvent
▪️Синтетический триггер - smTrigger
▪️Событие изменения статуса синтетического триггера - smProblem
▪️Правило - smRule
▪️Действие - smAction

🔺При добавлении макроса (объекта) в текстовое сообщение у пользователя появились следующие возможности:
▪️выбрать из предлагаемого системой списка группу, подгруппу и атрибут, явно определенные в системе (реализовано в виде подсказки справа от блока ввода);
▪️указать собственные группу, подгруппу и атрибут, о которых система явно не знает (например, лейблы первичного события)
▪️явно указать представление, в котором должна отобразиться информация из макроса при раскрытии :text или :json.

🔺Реализованные комбинации клавиш при работе с макросом:
▪️Esc - удаление макроса
▪️Tab - переход в конец ввода макроса
▪️Space/Enter (в любой части макроса) - выход из макроса. Поставит после макроса пробел

🔺Миграция старого представления макросов
Для всех настроенных шаблонов сообщений произведена следующая миграцию макросов:
▪️EventId → smProblem.id;
▪️EventLink → smProblem.link;
▪️StartClock → smProblem.startclock;
▪️EndClock → smProblem.endclock;
▪️RuleId → smRule.id;
▪️RuleName → smRule.name;
▪️Status → smTrigger.status;
▪️StTriggerName → smTrigger.name;
▪️StTriggerDenoscription → smTrigger.denoscription;
▪️HostName → plEvent.source.host.name;
▪️Priority → plEvent.source.trigger.priority;
▪️TriggerComments → plEvent.source.trigger.revealedComments;
▪️TriggerName → plEvent.source.trigger.revealedDenoscription

🔸Управление режимом обслуживания КЕ при помощи внешнего публичного API.
Мы выпустили первые методы публичного API. Теперь вы сможете управлять сервисными режимами КЕ внутри нашей системы из сторонних сервисов (например из JIRA или Trello), написав соответствующий простой коннектор. Ключевой особенностью данного функционала является возможность задания сервисного режима одновременно для большой группы КЕ, которую можно задать либо списком, либо ❗️ПАРАМЕТРИЧЕСКИ❗️, используя данные графа РСМ.

🔺Создание сервисного режима;
🔺Изменение сервисного режима;
🔺Получение информации о запланированных сервисных режимах;
🔺Отмена и завершение сервисного режима;
🔺Добавление пользовательских меток к сервисному режиму;
🔺Параметрическое задание области действия сервисного режима.
При создании и редактировании сервисных режимов, в списке Области влияния рядом с КЕ пользователь может указать, наследуется ли сервисный режим подчиненными ей КЕ. Для этого вводится дополнительный параметр, принимающий значения:
▪️Режим вводится только для указанной КЕ;
▪️Режим вводится для указанной КЕ и всех подчиненных ей;
▪️Режим вводится для указанной КЕ и подчиненных ей до указанного расстояния;

🔸Расширены некоторые функции в сервисе "Мои скрипты"
🔺Добавлена поддержка http прокси и basic auth в curl запросы;
🔺Функция smtp теперь не требует аутентификации;

🔹Решены следующие баги (куда без них):
▫️[SMCORE-1419] - Не работает поиск по КЕ в виджете "События за период";
▫️[SMCORE-1991] - Часть событий не обрабываются правилами и действиями из-за "Новое событие не меняет состояния существующего" ;
▫️[SMCORE-2020] - На панели РСМ на экране источников в столбце "Связанные КЕ" отображается только текущая КЕ

На этой неделе обязательно анонсируем, что ожидается в релизе 4.4.0. Планируем большой новый сервис, который обязательно вам пригодится ;)

Доброе утро и отличного пятничного настроения!

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

Решая данную задачу, мы серьезно расширили возможности нашей архитектуры по приему информации из внешних источников. Мы теперь сможем получать неструктурированные данные, что серьезно расширит спектр возможностей для приема данных из различных источников (не только систем мониторинга). И таки да - мы сможем собирать логи nginx без лишних проблем 👻

Про данное архитектурное решение мы обязательно позже подробнее расскажем, а теперь макеты:

Добрый вечер! А мы не с пустыми руками к Вам в гости 😀.
Вышел небольшой релиз 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.0:

🔸Новый компонент платформы 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.