开始使用告警
Elastic Stack Serverless
告警使您能够定义规则,这些规则可检测不同 Kibana 应用中的复杂条件,并在满足这些条件时触发操作。 告警与 可观测性、安全性、地图 和 机器学习 集成。 它可以从 Stack Management 集中管理,并提供一组内置的 连接器 和 规则 供您使用。

为了确保您可以访问告警和操作,请参阅设置和先决条件部分。
告警的工作原理是按计划运行检查以检测由规则定义的条件。当满足条件时,规则会将其跟踪为告警,并通过触发一个或多个操作来响应。操作通常涉及与 Kibana 服务或第三方集成的交互。 连接器使操作能够与这些服务和集成通信。 本节介绍所有这些元素以及它们如何协同工作。
规则指定在 Kibana 服务器上运行以检查特定条件的后台任务。Kibana 提供两种类型的规则:Kibana 内置的堆栈规则和由 Kibana 应用注册的规则。 有关更多信息,请参阅 规则类型。
规则由三个主要部分组成
- 条件:需要检测什么?
- 计划:应该何时/多久运行一次检测检查?
- 操作:检测到条件时会发生什么?
例如,在监视一组服务器时,规则可能
- 检查过去两分钟内每台服务器上的平均 CPU 使用率 > 0.9(条件)。
- 每分钟检查一次(计划)。
- 通过 SMTP 发送一封主题为
CPU on {{server}} is high
的警告电子邮件(操作)。
以下部分更详细地描述了规则的每个部分。
在底层,Kibana 规则通过在 Kibana 服务器上运行 JavaScript 函数来检测条件,这使其能够灵活地支持各种条件,从简单 Elasticsearch 查询的结果到涉及来自多个来源或外部系统的数据的繁重计算。
这些条件被打包并公开为规则类型。 规则类型隐藏了条件的底层细节,并公开了一组参数来控制要检测的条件的详细信息。
例如,索引阈值规则类型允许您指定要查询的索引、聚合字段和时间窗口,但底层 Elasticsearch 查询的详细信息被隐藏。
请参阅 规则类型,了解 Kibana 提供的规则以及它们如何表达其条件。
规则计划定义为后续检查之间的间隔,范围可以从几秒到几个月。
Kibana 中规则检查的间隔是近似的。 它们的计时会受到诸如任务被声明的频率以及系统上的任务负载等因素的影响。 有关更多信息,请参阅 告警生产注意事项。
当满足规则条件时,操作作为 Kibana 服务器上的后台任务运行。 同样,当不再满足规则条件时,恢复操作也会运行。 它们通过连接 Kibana 内部的服务或与第三方系统集成来发送通知。
在规则中定义操作时,您可以指定
- 一个连接器
- 一个操作频率
- 规则值到为该操作类型公开的属性的映射
Kibana 使用 连接器 简化了操作设置,而不是重复输入每个操作的连接信息和凭据。 例如,如果四个规则通过相同的 SMTP 服务发送电子邮件通知,则它们都可以引用相同的 SMTP 连接器。
操作频率 定义了操作运行的时间(例如,仅当告警状态发生变化时或在特定的时间间隔内)。 每种规则类型也有一组 操作组,它们会影响操作的运行时间(例如,当满足阈值时或当告警恢复时)。 如果您想减少收到的通知数量而不影响其及时性,请将操作频率设置为告警的摘要。 您将收到通知,其中汇总了您首选时间间隔内的新告警、正在进行的告警和已恢复的告警。
某些类型的规则允许您进一步细化运行操作的条件。 例如,您可以指定操作仅在特定时间范围内发生告警时或在与 KQL 查询匹配时运行。
因此,每个操作定义都是一个模板:提供了调用服务所需的所有参数,除了在检测到规则条件时才知道的特定值。
在服务器监视示例中,使用 email
连接器类型,并将 server
映射到电子邮件正文,使用模板字符串 CPU on {{server}} is high
。
当规则检测到条件时,它会创建一个包含条件详细信息的告警。
在检查条件时,规则可能会识别出条件的多个出现。 Kibana 会分别跟踪每个告警。 根据操作频率,每个告警都会发生一个操作或在指定告警摘要间隔内发生一个操作。
使用服务器监视示例,平均 CPU > 0.9 的每台服务器都将作为告警进行跟踪。 这意味着每当告警状态发生变化时,都会为每台超出阈值的服务器发送单独的电子邮件。
规则由条件、操作和计划组成。 当满足条件时,将创建告警,这些告警会呈现操作并调用它们。 为了使操作设置和更新更容易,操作使用连接器,这些连接器集中了用于与 Kibana 服务和第三方集成连接的信息。 以下示例将这些概念联系在一起
- 每当满足规则的条件时,就会创建一个告警。 此示例检查平均 CPU > 0.9 的服务器。 三台服务器满足该条件,因此创建了三个告警。
- 告警根据操作频率创建操作,只要它们未被静音或限制。 创建操作时,其属性将填充实际值。 在此示例中,满足阈值时创建了三个操作,并将模板字符串
{{server}}
替换为每个告警的相应服务器名称。 - Kibana 运行这些操作,通过使用第三方集成(如电子邮件服务)发送通知。
- 如果第三方集成具有连接参数或凭据,则 Kibana 会从相应的连接器中获取这些参数或凭据。
Watcher 和 Kibana 告警功能都用于检测条件,并且可以触发操作作为响应,但它们是完全独立的告警系统。
本节将阐明这两个系统的功能和意图的一些重要区别。
在功能上,告警功能的区别在于
- 计划的检查在 Kibana 上而不是在 Elasticsearch 上运行
- Kibana 规则通过规则类型隐藏了检测条件的详细信息,而 Watcher 提供了对输入、条件和转换的低级别控制。
- Kibana 规则通过告警跟踪并持久化每个检测到的条件的状态。 这使得可以静音和限制单个告警,并检测状态变化(例如解决)。
- 操作与警报相关联。操作针对检测到的每个条件发生触发,而不是针对整个规则触发。
从更高层面来看,警报功能支持跨用例的丰富集成,例如 APM、指标、安全 和 正常运行时间。预先打包的规则类型简化了设置,并隐藏了复杂、特定于领域的检测的细节,同时在 Kibana 中提供了一致的界面。