Alerting and action services

[njd5475]

Description

Across use cases there is no “one-size-fits-all” alerting feature. Logs, SIEM, APM, Uptime, Infrastructure, Monitoring, Maps, Machine Learning, Kibana Dashboards... alerts are relevant to all of these use cases, yet each one has unique needs for detecting conditions, expressing them, and showing them in context. Effective alerting and monitoring requires deep integration with a product.

To accommodate the different ways of detecting and taking action, Kibana will include a layered system of services where apps and features can integrate at the appropriate levels:

• Alert Base provides low level services for high scheduling and task management, audit logging/history, registering alerting primitives like types of alerts and types of action, and security.

• The Alert Lib layer allows for new types of “actions” and “alerts” to be easily defined and registered in Kibana. Default Kibana action types will include: email, slack, pagerduty, log, index, and webhook. Alert types will be defined by specific use cases (e.g. Monitoring, Uptime, SIEM define specific types tailored to that use case) but Kibana will also include general user-defined alert types, such as creating alert from an elasticsearch query or canvas expression.

• The Alert API layer includes: CRUD APIs for alerts; APIs for filtering and finding specific alerts; APIs for controlling behavior such as muting, throttling, and enable/disable.

• Alert UI includes centralized views for seeing alerts in context and managing them across use cases. as well as tools for correlating and making sense of alert history.

Project: https://github.com/elastic/kibana/projects/26

Phases

Phase 1

The first phase lays the foundation, focusing on scalable task management and scheduling, contracts for alerts and actions, and defining the main APIs

• Basic actions service
• Basic alerting service
• Secured queries using Elasticsearch tokens
• built-in action types
  • logging
  • slack
  • email
  • webhook
  • pagerduty
  • indexing

Phase 2

The second phase will allow use cases to integrate with the alerting system. This includes UI in Kibana to enable management and understanding of alerts across use-cases, and full featured alerting behavior

• Space aware alerts and actions
• Feature/access control
• Alert muting & throttling (including API)
• Alert UI for configuring, overview, details, and history
• Tagging, naming and ownership of alerts and actions (including API)
• History and audit log (including API)

Phase 3

• User defined alerts in Kibana ( for example expression style alerts)
• Snoozing alerts
• Import/Export of alerts and actions

[roncohen]

Is the "actions" and "alerting" services API described here up to date? cc @clintongormley

[njd5475]

Is the "actions" and "alerting" services API described here up to date? cc @clintongormley

The design parts here are outdated. There is a more formal proposal for just the Actions Service api RFC 0000 and hopefully be one for the Alerts Service to make it easier to track changes and elicit feedback as it has been difficult to keep this up to date.

[elasticmachine]

Pinging @elastic/kibana-stack-services

[ymao1]

Closing in favor of Alerting Project Board