...
The rules listed below are provisional and can be configured in line with your business tasks and objectives.
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 AMS throws an alert "server is unreachable";
- On SimpleOne instance, in accordance with the settings specified, the Exception event was created, identical to the alert and having Active status;
- The Debounce Engine has started to work, and the specified period should pass before any actions can be undertaken (for example, three minutes).
- Checking the status of the event associated with this alert (the monitoring system updates alert states, and the event 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 the warning events can be like "disk space is running out, X Mb left".
...
- The AMS throws an alert looking 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 having Active 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 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 events of the same user per minute.
...
| Field | Description |
|---|---|
| Subject | Event subject. |
| Service | Service that is related to this event. |
| Related CI | CI related to this event. |
| Type | Event type. Available options:
|
| State | The event state correlated with the CI state in the Incident table. |
| Monitoring state | The event state synchronized with the CI state in the AMS. Available choice options:
|
...
| Field | Description |
|---|---|
| Object Count | This numeral field specifies how many ITSM Events it requires to create an incident. |
| Event Type | Event type. Available options:
|
| Debounce Period | The period between throwing an event and raising and 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 that is related to this event. |
| Related CI | CI related to this event. |
| Set Packing | 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. |
...