Переделка механизма заведения аварий по опросу

Описание

Сейчас при возникновении проблемных ситуаций при опросе (Discovery) на устройство (ManagedObject) открывается зонтичная авария (Umbrella Alarms) к которой прикрепляется непосредственная авария. Данный механизм достаточно неудобен в работе по следующим причинам:

• Для обозначения авария используется поле root, отвечающее за корреляцию аварий. По этой причине в корреляции может участвовать только сам зонтик (Umbrella)
• Поскольку для открытия аварии механизм опроса то она не попадает в коррелятор. Из-за этого большая часть функционала FM (коррелятция, эскалация, обработчики) не доступно для работы
• Пользователям в UI не всегда очевидна проблемная ситуация, поскольку подчинённе аварии по умолчанию скрыты из интерфейса и чтобы посмотреть проблемные ситуации необходимо либо зайти в зонтичную аварию. либо включить отображение подчинённых аварий.

Предложение

Предложение переделать механизм для работы через коррелятор и добавить настройки для аварий по опросу в Managed Object Profile.

Дискавери формирует следующие группы аварий:

• Аварии по опросу - (Discovery)
• Аварии по ошибкам конфигурации - (Config)
• Аварии по порогу Threshold

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

Для этого в аварию необходимо добавить поле source, указатель на источник аварии:

• event - событие, генерится классификатором
• discovery - аварии по ошибкам опроса
• config - аварии по валидации конфига
• metrics - аварии по порогу

Это позволит разделить логику работы с разными типами аварий. В текущей реализации уникальность аварии обеспечивается по идентификатору ManagedObject + path, предлагается заменить его на ManagedObject + Descriminator настройки Descriminatora находятся в классе аварии. В данном случае работа строится следующим образом:

1. На стороне опроса discovery формируется сообщение со текущим состоянием опроса по группам:
   • source - источник аварии
   • managed_object - ManagedObject, создавший аварию
   • alarms - список аварийных событий
     • timestamp - время создания
     • alarm_class - имя класса аварии (Alarm Class)
     • vars - переменные
2. Сообщение отправляется в сторону коррелятора в очередь dispose
3. При приёме сообщения обрабатываем его согласно полю source
4. Согласно классу аварии - (Alarm Class) производим расчёт discriminatora
5. Производим поиск по Активным авариям связки - source + managed_object + AlarmClass + discriminator
   • Если авария в активных не найдена - открываем новую аварию по информации из сообщения
   • Если авария найдена - обновляем поле last_update согласно timestamp
   • Если после обработки всех аварийных событий остались не обработанные аварии из source + managed_object закрываем их
6. Повторяем для следующего источника
7. Если пройдены все источники - завершаем обработку и переходим к следующему сообщению.

Настройки в Managed Object Profile

Для аварий по опросу (исключая аврии по порогам и конфигурации) отсутствуют настройки. Хотелось бы устранить данный недостаток и добавить таковые, для удобства. Настройки необходимо разместить в профиле объекта - Managed Object Profile:

• alarm_class - Класс аварии (Alarm Class), для которого делаются настройки
• action - Действие
  • Alarm - поднять аварию
  • Log - Записать в лог опроса
  • Ignore - игнорировать
• is_fatal - Остановить опрос
• weight - вес аварии