Alerting

Alerting allows you to define rules to detect complex conditions within different Kibana apps and trigger actions when those conditions are met. Alerting is integrated with Observability, Security, Maps and Machine Learning, can be centrally managed from the Management UI, and provides a set of built-in connectors and rules (known as stack rules) for you to use.

Alerting works by running checks on a schedule to detect conditions defined by a rule. When a condition is met, the rule tracks it as an alert and responds by triggering one or more actions. Actions typically involve interaction with Kibana services or third party integrations. Connectors allow actions to talk to these services and integrations. This section describes all of these elements and how they operate together.

A rule specifies a background task that runs on the Kibana server to check for specific conditions. Kibana provides two types of rules: stack rules that are built into Kibana and the rules that are registered by Kibana apps. Refer to Rule types for more information.

A rule consists of three main parts:

For example, when monitoring a set of servers, a rule might:

The following sections describe each part of the rule in more detail.

Under the hood, Kibana rules detect conditions by running a Javascript function on the Kibana server, which gives it the flexibility to support a wide range of conditions, anything from the results of a simple Elasticsearch query to heavy computations involving data from multiple sources or external systems.

These conditions are packaged and exposed as rule types. A rule type hides the underlying details of the condition, and exposes a set of parameters to control the details of the conditions to detect.

For example, an index threshold rule type lets you specify the index to query, an aggregation field, and a time window, but the details of the underlying Elasticsearch query are hidden.

See Rule types for the rules provided by Kibana and how they express their conditions.

Rule schedules are defined as an interval between subsequent checks, and can range from a few seconds to months.

Actions are invocations of connectors, which allow interaction with Kibana services or integrations with third-party systems. Actions run as background tasks on the Kibana server when rule conditions are met.

When defining actions in a rule, you specify:

The result is a template: all the parameters needed to invoke a service are supplied except for specific values that are only known at the time the rule condition is detected.

In the server monitoring example, the email connector type is used, and server is mapped to the body of the email, using the template string CPU on {{server}} is high.

When the rule detects the condition, it creates an alert containing the details of the condition, renders the template with these details such as server name, and runs the action on the Kibana server by invoking the email connector type.

See Connectors for details on the types of connectors provided by Kibana.

When checking for a condition, a rule might identify multiple occurrences of the condition. Kibana tracks each of these alerts separately and takes an action per alert.

Using the server monitoring example, each server with average CPU > 0.9 is tracked as an alert. This means a separate email is sent for each server that exceeds the threshold.

Actions often involve connecting with services inside Kibana or integrating with third-party systems. Rather than repeatedly entering connection information and credentials for each action, Kibana simplifies action setup using connectors.

Connectors provide a central place to store connection information for services and integrations. For example if four rules send email notifications via the same SMTP service, they can all reference the same SMTP connector. When the SMTP settings change, you can update them once in the connector, instead of having to update four rules.

A rule consists of conditions, actions, and a schedule. When conditions are met, alerts are created that render actions and invoke them. To make action setup and update easier, actions use connectors that centralize the information used to connect with Kibana services and third-party integrations. The following example ties these concepts together:

Alerting and Watcher are both used to detect conditions and can trigger actions in response, but they are completely independent alerting systems.

This section will clarify some of the important differences in the function and intent of the two systems.

Functionally, Alerting differs in that:

At a higher level, Alerting allows rich integrations across use cases like APM, Metrics, Security, and Uptime. Pre-packaged rule types simplify setup and hide the details of complex, domain-specific detections, while providing a consistent interface across Kibana.