Event Correlation Engine

You can integrate your SimpleOne instance with any preferred active monitoring system (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).

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.

The processing of exception events using events correlation engine is listed below (we will use the example with the server):

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 states, 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.

Warning Events

Warning events have less priority than exceptions. An example of the warning events can be like "disk space is running out, X Mb left".

The processing of warning events using events correlation engine is listed below (we will use the example with the disk space):

1. Active monitoring system throws an alert "disk space is running out, X Mb left".
2. On SimpleOne instance, in accordance with the settings specified, the Warning event was created, identical to the alert and having Active status;
3. As opposed to the Exception events, we do not launch the Debounce engine and do not start a countdown. In accordance with the settings specified, to launch the Debounce engine, there must be two active Warning events for this alert.
4. If the second Warning event was received, then the Debounce engine launches and the specified period should pass before any actions can be undertaken.
5. Checking the status of the events associated with this alert (the monitoring system updates alert statuses, and the event statuses synchronize with them):
   1. If all the events are still Active - raise the Incident immediately;
   2. If at least one event is Inactive, then the Incident will not be raised.

Information Events

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 many similar events for a specified period, for example, ten login-logoff events of the same user per minute.

The processing of information events using events correlation engine is listed below (we will use the example with the logins):

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.изованы три типа ивентов: exception, warning, information. 

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

1. в какой-то момент (такт синхронихзации) от внешней системы мониторинга приходит alert "сервер такой-то недоступен (красное событие)". 
2. на стороне симпл, в соответствии с заданными настройками, создался ивент с типом exception, идентичный алерту, сервер такой-то недоступен. он имеет статус active.
3. У нас задано: если возник один exception event - значит, надо создать инцидент. Мы готовимся это сделать. Сработал механизм автокорреляции. Его суть в том, что когда мы создаем инцидент из ивента, т.е. из ивента категории иксепшен мы создаем инцидент безусловно, из ивента категории варнинг нам нужно накопить такой же ивент, чтобы было не менее 2. Ивентов категории информейшен должно быть аномальное количество за промежуток времени, например, (такие ивенты самые незначительные, это, например, пользователь залогинился или разлогинился), это нормально иметь такие ивенты и ненормально, если у нас за 1 минуту поступит 50 таких ивентов, нужно в таком случае создавать инцидент.
4. Вот когда у нас за период времени аномальный всплеск количества таких ивентов свыше заданного, у нас создаётся инцидент.

Вот зависимость от типа ивента и дальнейшие действия по регистрации инцидента это и называется механизм корреляции ивентов. Механизм дебаунс накладывается поверх него.

1. Пришел ивент категории иксепшен.
2. Мы готовы создать инцидент, но по истечении периода антидребезга.
3. Ждем три минуты, заданный период антидребезга.
4. Прошел этот период, мы смотрим на состояние ивента, а он уже "позеленел", т.е. состояние inactive. Потому что система мониторинга пролила новый статус на него за очередной такт синхронизации. И алерт позеленел, и ивент позеленел, они синхронизируются, соответственно, мы не создаем инцидент. Антидребезг помог нам избежать создания инцидента, который сразу же будет неактуален.

Ситуация другая

1. Пришел ивент категории иксепшен.
2. Мы так же готовы создать инцидент., но надо подождать на антидребезг.
3. Антидребезг прошел, мы вернулись, система мониторинга подтверждает активный статус ивента, он действительно актуален, т.е. активен этот ивент, и мы незамедлительно создали инцидент.

В случае варнингов. Тут логика сложнее.

Если тут сервер был недоступен, то у нас здесь просто, например, превышение порогового значения жесткого диска, осталось 50 мб. Мы создаем ивент на основе этого события. Поскольку у нас тип ворнинг, мы не кидаемся сразу запускать антидребезг и создавать инцидент. У нас по правилам, если ивент варнинг, то надо подождпть такого же второго активного ивента, что и происходит. Через заданный промежуток времени синхронизация происходит, доставляется ивент, уже с другим порогом, осталось 40 мегабайт. Правило удовлетворилось, мы приступаем к антидребезгу. Мы ожидаем антидребезг 3 минуты, как настроено, возвращаемся и видим, что немного место освободилось и стало место 45 свободно. Т.е. остался один ивент. Мы инцидент не создаем. Возвращаемся в исходное состояние. Опять приходит ивент о том, что 50 мегабайт осталось, ждём следующий, ничего не делаем, приходит ещё один, что осталось 40, мы опять запускаем антидребезг, ждём, тут ещё насыпалось, что осталось 30 и 20 мегабайт. Мы незамедлительно создаем инцидент о том, что заканчивается место на диске. 

А в случае информейшен задается период времени. Нам нужно, чтобы поступили однотипные события, одинаковые за период времени , т.е. надо, чтобы было, скажем, больше 10 за 1 минуту таких. Этим и отличается тип информейшен от остальныхт типов.

Антидребезг - это только задержка в регистрации, а автокорреляция - это как раз тип ивента, один из трёх, иксепшен, варнинг, информейшен, и правило, то есть, задача этих правил, настройка этих правил. Эксепшены тоже гибки, может, какой-нибудь клиент тоже захочет, если эксепшен, надо, чтобы было 2 экспешена, и тогда только создавался инцидент.