告警
编辑告警
编辑告警功能使您能够定义规则，这些规则可以检测不同 Kibana 应用中的复杂条件，并在满足这些条件时触发操作。告警功能与 可观测性、安全性、地图 和 机器学习 集成。它可以从 堆栈管理 中集中管理，并提供一组内置的 连接器 和 规则 供您使用。
要确保您可以访问告警和操作，请参阅设置和先决条件部分。
告警的工作原理是按计划运行检查，以检测由规则定义的条件。当满足条件时，规则会将其跟踪为告警，并通过触发一个或多个操作来响应。操作通常涉及与 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 的差异
编辑Watcher 和 Kibana 告警功能都用于检测条件，并且可以触发操作作为响应，但它们是完全独立的告警系统。
本节将阐明两个系统在功能和意图上的一些重要差异。
在功能上，告警功能的不同之处在于
- 计划的检查在 Kibana 上而不是在 Elasticsearch 上运行
- Kibana 规则通过规则类型隐藏了检测条件的详细信息，而 Watcher 提供了对输入、条件和转换的低级控制。
- Kibana 规则通过告警跟踪并保留每个检测到的条件的状态。这使得可以静音和节流单个告警，并检测状态变化，例如解决。
- 操作与告警相关联。操作是针对每次检测到的条件发生而触发的，而不是针对整个规则。
在更高的层次上，告警功能允许跨越诸如 APM、指标、安全性 和 正常运行时间 等用例的丰富集成。预先打包的规则类型简化了设置并隐藏了复杂的、特定于域的检测的详细信息，同时在 Kibana 中提供了一致的接口。