Page History

You can integrate your SimpleOne instance with some any preferred active monitoring system for 

Теперь будем сокращать

Что делает механизм автокорреляции (описать, что это такое и зачем он нужен)

In SimpleOne, you can integrate

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

У нас настроен обмен данными между внешней системой мониторинга и системой симпл. Регулярный, по апи, например, раз в 5 сек.

У нас есть три типа ивентов: exception, warning, information. Отсортированы по убыванию важности.

Event correlation engine

In SimpleOne, three types of events are implemented: (AMS) for supervising the stability and performance of your system. The AMS primary function is to query the service or CI status and generate alerts if necessary. After that, using the data exchange mechanism between the AMS and the SimpleOne instance, based on these alerts, events are created typified by the alert priority (these may be exception events, warning events, and information events (sorted by priority in descendant order). This typification ).

The event correlation engine allows configuring the system behavior rules depending on the event type (for example, whether or not to create an incident if an Exception event has been thrown).

Exception Events

Exception events are the highest priority ones from this list. An example of the exception event can be a server or any other crucial service unavailability.

...

1. Active monitoring system throws an alert "server is unreachable";
2. On SimpleOne instance, in accordance with the settings specified, the Exception event was created, identical to the alert and having Active status;
3. The Debounce engine has started to work, and the specified period should pass before any actions can be undertaken (for example, three minutes).
4. Checking the status of the event associated with this alert (the monitoring system updates alert statusesstates, and the event statuses synchronize with them):
   1. If the event status is still Active - raise the Incident immediately;
   2. If the event status has changed to Inactive, then the Incident will not be raised.

...

Information events are the lowest-priority events, and they are merely informational. An example of the information event is user authorization notification. In there, it is only necessary to gain a number of many similar events for a specified period, for example, ten login-logoff events of the same user per minute.

...

1. Event Monitoring collects ten login-logoff events of the same user per minute;
2. After that, it raises an incident about suspicious activity. In this case, the Debounce engine is not used.

В данном случае даже не используется механизм Антилребезга.

1. В какой-то момент, в очередной такт синхронизации система мониторинга сообщает "сервер такой-то недоступен (красное событие)".
2. на стороне симпл, в соответствии с заданными настройками, создался ивент с типом exception, идентичный алерту, сервер такой-то недоступен. он имеет статус active.
3. Ждём заданный период антидребезга (например, три минуты)
4. Смотрим статус ивента, соответствующего этому алерту (система мониторинга регулярно обновляет статусы алертов, а статусы ивентов синхронизируются с ними).
   1. Если статус ивента по прежнему active - незамедлительно создаем инцидент
   2. Если статус ивента сменился на inactive - инцидент не создаётся.

Warning - это менее приоритетные ивенты. Например, если заканчивается свободное дисковое пространство. Тут логика работает немного иначе.

1. В какой-то момент, в очередной такт синхронизации система мониторинга сообщает "на сервере таком-то осталось столько-то свободного дискового пространства" (оранжевое событие);
2. Мы создаем ивент категории warning, но антидребезг пока не запускаем. По нашим настройкам, нам необходимо дождаться второго такого же активного ивента.
3. Поступил второй event типа warning. Если сейчас у нас два активных eventa типа warning по одному alert, то
4. Запускаем механизм антидребезга, ждём заданный период антидребезга (например, три минуты).
5. Смотрим на статусы eventов, соответствующих этому alert (система мониторинга регулярно обновляет статусы алертов, а статусы ивентов синхронизируются с ними).
   1. Если оба ивента имеют статус active - незамедлительно создаем инцидент
   2. Если хотя бы один ивент перешёл в inactive - инцидент не создаётся.

суть механизма автокорреляции 

exception

...

1. изованы три типа ивентов: exception, warning, information. 

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

...