You can integrate your SimpleOne instance with any preferred active monitoring system (AMS) for supervising the stability and performance of your system. The AMS 's primary function is to query the state of service or CI status and generate alerts if necessary. Based 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 (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 (for example, whether or not to create an Incident if an Exception event has been thrown).
The rules listed below are provisional and can be configured in line with your business tasks and objectives.
...
Exception events are the highest priority ones from event typesthis list. An example of an the exception event can be a server or any other crucial service unavailability.
The processing of exception events using the events correlation engine is listed below (we will use the example with the server):
- The AMS throws an alert "server is unreachable".
- On a SimpleOne instance, in accordance with the settings specified, the Exception event was created, identical to the alert , and has the having Active state status.
- The The Debounce Engine has started to work, and the specified period should pass before any actions can be undertaken . For (for example, the period is three minutes).
- Checking the state status of the event associated with this alert (the monitoring system updates alert states, and the event states statuses synchronize with them):
- If the event
- status is still Active - submit an incident immediately.
- If the event
- status has changed to Inactive, then the incident will not be created.
Warning Events
...
Warning events have less priority than exceptions. An example of a the warning event events can be like "disk space is running out, X Mb left".
The processing of warning events using the events correlation engine is listed below (we will use the example with the disk space):
- The AMS throws an alert looking like alike "disk space is running out, X Mb left".
- On SimpleOne instance, in accordance with the settings specified, the Warning event was created, identical to the alert , and has the having Active state status.
- 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.
- If the second Warning event was received, then the Debounce engine launches and the specified period should pass before any actions can be undertaken.
- Checking the status of the events associated with this alert (the monitoring system updates alert statuses, and the event statuses synchronize with them):
- If all the events are still Active - raise the Incident immediately.
- 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 an the information event is a user authorization notification. In there, it is only necessary to gain many similar events for a specified period, for example, ten login 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):
- The AMS throws an alert looking like alike "John Doe tries to log in ten times per minute".
- The Event Monitoring module collects ten login events of the same user per minute.
- After that, it raises an incident about suspicious activity. In this case, the the Debounce Engine is not used.
This picture illustrates the basic principles of the work of the Event Correlation engine.
ITSM Event form table fields
Field | Mandatory | Description | Number | N | Updated by | Description |
---|---|---|---|---|---|---|
Subject | Event subject. | |||||
Service | Service that is related to this event. | |||||
Related CI | CI related to this event. | |||||
Type | N | Type | N | Event type. Available options:
| Created by | N |
State | N | The event state correlated with the CI state in the Incident table. | Description | N | Incident | N |
Related CI | N | CI related to this event. | ||||
Service | N | Service that is related to this event. | Impact | N | Urgency | N |
Subject | N | Event subject. | ||||
Event Set | N | Monitoring state | NThe event state is synchronized with the CI state in the AMS. Available choice options:
| Rule | N
Event Rule form table fields
Field | MandatoryDescription | Name | N | |
---|---|---|---|---|
Object Count | This numeral field specifies how many ITSM Events it requires to create an incident | Specify the rule name. | ||
Event Type | N | Define the eventEvent type. Available options:
| ||
Related CI | N | Specify the CI related to this event. | ||
| ||||
Debounce Period | The period between throwing an event and raising an incident. | |||
Event Subject Substring | A search substring used for events searching and their binding into a set on a common basis. | |||
Limit Processing Time | Select this checkbox if you need to limit the timeframes of the processing for the events. | |||
Processing Period | If the attribute Limit Processing Time was set, then you can limit this period there. | |||
Service | Service | Service | N | Define the service that is related to this event. |
Incident Subject | N | Specify the subject of the incident that will be created. | ||
Object Count | N | Specify the number of ITSM Events after which the incident is created. | ||
Related CI | CI related to this event. | |||
Event Set | This attribute is that events are processed like a single set. In this field, the value of the Object Count field is taken into account. | Debounce Period | Y | Define the period between throwing an event and raising an incident. |