This documentation contains work-in-progress information for future Elastic Stack and Cloud releases. Use the version selector to view supported release docs. It also contains some Elastic Cloud serverless information. Check out our serverless docs for more details.
« Alerting Create and manage rules »
Elastic Docs ›Kibana Guide [master] ›Alerting

Alerting set up

edit

Alerting set up

edit

Kibana alerting features are automatically enabled, but might require some additional configuration.

Prerequisites

edit

If you are using an on-premises Elastic Stack deployment:

If you are using an on-premises Elastic Stack deployment with security:

The alerting framework uses queries that require the search.allow_expensive_queries setting to be true. See the scripts documentation.

Production considerations and scaling guidance

edit

When relying on alerting and actions as mission critical services, make sure you follow the alerting production considerations.

For more information on the scalability of alerting features, go to Scaling guidance.

Security

edit

To use alerting features in a Kibana app, you must have the appropriate feature privileges:

Action Kibana privileges

Give full access to manage alerts, connectors, and rules in Stack Management
  • All for the Management > Stack Rules feature.
  • All for the Management > Rules Settings feature.
  • All for the Management > Actions and Connectors feature.

The Actions and Connectors feature privilege is required to manage connectors. To add rule actions and test connectors, you require only Read privileges.

By default, All privileges for the Rules Settings feature include authority to edit flapping detection settings unless you customize the sub-feature privileges.

[preview] This functionality is in technical preview and may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features. To create a rule that uses the Cases connector, you must also have all privileges for the Cases feature.

The rule type also affects the privileges that are required. For example, to create or edit machine learning rules, you must have all privileges for the Analytics > Machine Learning feature. For Stack Monitoring rules, you must have the monitoring_user role. For Observability rules, you must have all privileges for the appropriate Observability features. For Security rules, refer to Detections prerequisites and requirements.

Give view-only access to alerts, connectors, and rules in Stack Management
  • Read for the Management > Stack Rules feature.
  • Read for the Management > Rules Settings feature.
  • Read for the Management > Actions and Connectors feature.

The rule type also affects the privileges that are required. For example, to view machine learning rules, you must have read privileges for the Analytics > Machine Learning feature. For Stack Monitoring rules, you must have the monitoring_user role. For Observability rules, you must have read privileges for the appropriate Observability features. For Security rules, refer to Detections prerequisites and requirements.

Give view-only access to alerts in Discover or Dashboards
  • Read index privileges for the .alerts-* system indices.

Revoke all access to alerts, connectors, and rules in Stack Management, Discover, or Dashboards
  • None for the Management > Stack Rules feature.
  • None for the Management > Rules Settings feature.
  • None for the Management > Actions and Connectors feature.
  • No index privileges for the .alerts-* system indices.

For more information on configuring roles that provide access to features, go to Feature privileges.

API keys

edit

Rules are authorized using an API key. Its credentials are used to run all background tasks associated with the rule, including condition checks like Elasticsearch queries and triggered actions.

If you create or edit a rule in Kibana, an API key is created that captures a snapshot of your privileges at the time of the edit. The following actions regenerate the API key in Kibana:

  • Creating a rule
  • Updating a rule

When you disable a rule, it retains the associated API key which is reused when the rule is enabled. If the API key is missing when you enable the rule (for example, in the case of imported rules), it generates a new key that has your security privileges.

You can update an API key manually in Stack Management > Rules or in the rule details page by selecting Update API key in the actions menu.

If you manage your rules by using Kibana APIs, they support support both key- and token-based authentication as described in Authentication. To use key-based authentication, create API keys and use them in the header of your API calls as described in API Keys. To use token-based authentication, provide a username and password; an API key that matches the current privileges of the user is created automatically. In both cases, the API key is subsequently associated with the rule and used when it runs.

If a rule requires certain privileges, such as index privileges, to run and a user without those privileges updates the rule, the rule will no longer function. Conversely, if a user with greater or administrator privileges modifies the rule, it will begin running with increased privileges. The same behavior occurs when you change the API key in the header of your API calls.

Restrict actions

edit

For security reasons you may wish to limit the extent to which Kibana can connect to external services. You can use Action settings to disable certain Connectors and allowlist the hostnames that Kibana can connect with.

Space isolation

edit

Rules and connectors are isolated to the Kibana space in which they were created. A rule or connector created in one space will not be visible in another.

Cross-cluster search

edit

If you want to use alerting rules with cross-cluster search, you must configure privileges for CCS and Kibana. Refer to Remote clusters.

« Alerting Create and manage rules »