Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • N noc
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 427
    • Issues 427
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 18
    • Merge requests 18
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • External wiki
    • External wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • noc
  • noc
  • Issues
  • #1683

Closed
Open
Created Oct 04, 2021 by Andrey Vertiprahov@aversantDeveloper

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

Описание

Сейчас при возникновении проблемных ситуаций при опросе (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 - вес аварии
Edited Oct 06, 2021 by Andrey Vertiprahov
Assignee
Assign to
Time tracking