You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/user/alerting/alerting-getting-started.asciidoc
+6-5Lines changed: 6 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -123,14 +123,15 @@ image::images/alert-concepts-connectors.svg[Connectors provide a central place t
123
123
[float]
124
124
=== Summary
125
125
126
-
An _alert_ consists of conditions, _actions_, and a schedule. When conditions are met, _alert instances_ are created that render _actions_ and invoke them. To make action setup and update easier, actions refer to _connectors_ that centralize the information used to connect with {kib} services and third-party integrations.
126
+
An _alert_ consists of conditions, _actions_, and a schedule. When conditions are met, _alert instances_ are created that render _actions_ and invoke them. To make action setup and update easier, actions refer to _connectors_ that centralize the information used to connect with {kib} services and third-party integrations. The following example ties these concepts together:
127
127
128
128
image::images/alert-concepts-summary.svg[Alerts, actions, alert instances and connectors work together to convert detection into action]
129
129
130
-
* *Alert*: a specification of the conditions to be detected, the schedule for detection, and the response when detection occurs.
131
-
* *Action*: the response to a detected condition defined in the alert. Typically actions specify a service or third party integration along with alert details that will be sent to it.
132
-
* *Alert instance*: state tracked by {kib} for every occurrence of a detected condition. Actions as well as controls like muting and re-notification are controlled at the instance level.
133
-
* *Connector*: centralized configurations for services and third party integration that are referenced by actions.
130
+
. Anytime an *alert*'s conditions are met, an *alert instance* is created. This example checks for servers with average CPU > 0.9. Three servers meet the condition, so three instances are created.
131
+
. Instances create *actions* as long as they are not muted or throttled. When actions are created, the template that was setup in the alert is filled with actual values. In this example three actions are created, and the template string {{server}} is replaced with the server name for each instance.
132
+
. {kib} invokes the actions, sending them to a 3rd party *integration* like an email service.
133
+
. If the 3rd party integration has connection parameters or credentials, {kib} will fetch these from the *connector* referenced in the action.
0 commit comments