当前位置：主页 > 查看内容

Kibana 的 Alert

发布时间：2021-05-17 00:00| 有位朋友查看

简介：创作人：金端 Kibana 的 Alert 模块主要用于 Elastic Stack 的监控告警。以一种相对较低的使用成本，将复杂的查询条件，编辑完成后监控不同的 Elastic Stack 的技术产品中产生的数据，最终把符合条件的告警信息以需要的方式反馈给用户。 Alert 的组成 Alert……

创作人：金端

Kibana 的 Alert 模块主要用于 Elastic Stack 的监控告警。以一种相对较低的使用成本，将复杂的查询条件，编辑完成后监控不同的 Elastic Stack 的技术产品中产生的数据，最终把符合条件的告警信息以需要的方式反馈给用户。

Alert 的组成

Alert 主要由三个部分组成：

Condition 条件

也是 Alert Type，检测需要执行的查询或者统计。

Condition 的概念执行主要由 alert type 承担。Alert Type 通过简单的参数设置将涉及 Elasticsearch 的查询结果和其它数据源的复杂计算完美实现。比如：监控的程序 APM 数据2分钟内 CPU 使用均值高于0.9；某个业务数据索引中，10分钟内购买失败次数占比超总量的30%等等.Schedule 检测周期

Alert 的执行周期。Schedule 的设置按照每隔多久循环来设置，从每秒到每月不等，但并不能设置具体哪月哪天。

Action 告警动作

即满足告警条件后需要执行的操作，主要是将需要的告警信息发送给第三方系统，在 Kibana 后台执行。

Action 可以分解为三个要素：

action type，发送的第三方系统类型定义。connection，告警发送的连接信息，比如email的host和端口等properties，告警信息所需要引用的参数值。

Alert 与 Elasticsearch 的 Watcher不同的是，Alert 运行在 Kibana 而不是 Elasticsearch，相关任务数据也是存储在 Kibana 的索引中，而 Elasticsearch 的 Watcher 数据则是在 Watcher 的索引中。

在更高的层次上，Kibana Alert 允许跨用例（如 APM、Metrics、Scurity 和 Uptime）进行丰富的集成。预先打包的 Alert Type 简化了设置，隐藏了复杂的检测细节，同时提供了跨 Kibana 的一致接口。

Alert Instances 的概念和抑制重复告警

在检查一个 condition 条件时，Alert 可能会识别该条件的多次出现。每出现一次符合 condition 条件的情况，Kibana 就生成一个 Alert Instances，即警报实例。那么 Kibana 分别跟踪每个警报实例，并对每个实例采取行动。

重复告警

以下面的图示例，将每个平均 CPU 为 0.9 的服务器作为 Alert Instance 进行跟踪。然后将每个超过阈值的服务器都将发送单独的电子邮件。

那就会带来一个问题，当 Alert Instances 过多的时候，就会造成大量通知重复发送，即 Alert Noise 的现象。

比如一个警报每分钟监控三个服务器的 CPU 使用情况 0.9，就发送邮件通知工作人员:

第一分钟：服务器 X123 的 CPU 0.9。

其中一封邮件发送通知工作人员服务器 X123 的 CPU 过高。

第二分钟：X123 和 Y456 的 CPU 0.9。

发送了两封邮件，一封是关于 X123 的，一封是关于Y456的。

第三分钟：X123, Y456, Z789 的 CPU 0.9。

发送了三封邮件，分别是 X123，Y456，Z789。

在上面的例子中，对于相同的条件，在3分钟的时间内，向服务器 X123 发送了3封邮件。

抑制重复告警

Kibana 针对这个情况做了抑制重复通知的优化，主要是通过设置通知间隔来抑制重复多余的告警。比如在上面的例子中，将警报重新通知间隔设置为5分钟，那么 Alert 发送通知的情况则如下：

第一分钟：服务器 X123 0.9

邮件发送报告服务器 X123 的 CPU 过高；

第二分钟：X123 和 Y456 0.9

邮件发送报告服务器 Y456 的 CPU 过高；

第三分钟：X123, Y456, Z789 0.9

邮件发送报告服务器 Z789 的 CPU 过高。

当然过了五分钟后，如果服务器 X123 0.9还是存在，那么继续会发送邮件，报告服务器 X123 的 CPU 过高。

Kibana Alert 的实现机制

Kibana Alert 将 Alert Check 的信息和 Action 的信息，持久化在 Elasticsearch 在后台执行。这有两个主要好处:

持久性：所有的任务相关的信息都存储在 Elasticsearch 中，所以如果 Kibana 重新启动，Alert 和 Action 将从它们停止的地方恢复；伸缩性：多个 Kibana 实例可以从 Elasticsearch 中读取和更新相同的任务队列，允许 Alert 和 Action 跨实例分布。如果现有的 Alert 执行数量超出了现有的 Kibana 实例的容量上限，可以增加额外的 Kibana 实例。Kibana 后台任务的执行机制每隔3秒轮循 Elasticsearch 任务索引以查找过期任务；任务执行后在 Elasticsearch 索引中更新，使用乐观并发控制来防止冲突；任务在 Kibana 服务器上运行。每个 Kibana 实例最多可以运行 10 个并发任务，因此每个间隔最多可以声明 10 个任务；对于重复后台检查的 Alert，任务完成后将按照检查间隔再次调度。

因为每3秒轮询一次任务，并且每个 Kibana 实例只能同时运行10个任务，所以 Alert 和 Action 任务可能会在以下情况延迟运行：

警报使用较小的检查间隔。最低间隔时间可能是 3 秒，但建议间隔时间为 30 秒或更高许多警报或操作必须同时运行。在这种情况下，挂起的任务将在 Elasticsearch 中排队，并且每隔 3 秒从队列中取出 10 个任务长时间运行的任务占用槽位的时间较长，留给其他任务的槽位较少完整的 Alert 流程

Alert 由 Condition（条件）、Action 和 Schedule 组成。当条件满足时，就会创建警报实例来呈现和调用操作。为了使 Action 设置和更新更容易，Action 包含了与第三方连接交互的 Connector 。

下面的例子将这些概念联系在一起:

只要警报的条件得到满足，就会创建一个警报实例。这个示例检查平均 CPU 为 0.9 的服务器。三个服务器满足条件，因此创建了三个实例；Action 执行时，警报中设置的模板将被实际值填充。在这个示例中，创建了三个操作，模板字符串 {{server}} 被替换为每个实例的服务器名；Kibana 调用这些 Action，将它们发送给第三方集成，比如邮件服务；发送这些信息时，Action 会结合 Connector 中设置的信息发送。比如：邮件的 host/port/用户名/密码。如何配置 Alert

目前 Kibana 提供了一种内置的警报类型：索引阈值类型（index threshold）。索引阈值警报类型，允许您指定要查询的索引、聚合字段和时间窗口。但底层 Elasticsearch 查询的详细信息是隐藏的。根据设定的查询条件，将结果与阈值进行比较，并在满足阈值时进行后续的调度执行。

操作示范

在 Stack management 的 Alert 中 Create alert，新建一个名为 test-alert 的告警。该告警用于检查索引test-es中fail_num的累计数量，test-alert每分钟检查一次，最多5分钟告警通知一次，标签为test。

索引test-es的数据如下：

PUT test-es
POST test-es/_mapping
 "properties" : {
 "@timestamp" : {
 "type" : "date",
 "format" : "yyyy/MM/dd HH:mm:ss||yyyy/MM/dd||epoch_millis"
 "fail_num" : {
 "type" : "long"
 "user" : {
 "properties" : {
 "id" : {
 "type" : "text",
 "fields" : {
 "keyword" : {
 "type" : "keyword",
 "ignore_above" : 256
POST _bulk
{ "create" : { "_index" : "test-es", "_id" : "1" } }
{ "@timestamp" : "2021/04/20 23:30:30" ,"user.id":"may","fail_num":"1"}
{ "create" : { "_index" : "test-es", "_id" : "2" } }
{ "@timestamp" : "2021/04/20 23:33:31" ,"user.id":"may","fail_num":"4"}
{ "create" : { "_index" : "test-es", "_id" : "4" } }
{ "@timestamp" : "2021/04/20 23:46:30" ,"user.id":"jack","fail_num":"1"}
{ "create" : { "_index" : "test-es", "_id" : "5" } }
{ "@timestamp" : "2021/04/20 23:50:30" ,"user.id":"may","fail_num":"6"}
{ "create" : { "_index" : "test-es", "_id" : "6" } }
{ "@timestamp" : "2021/04/20 23:49:30" ,"user.id":"jack","fail_num":"3"}
{ "create" : { "_index" : "test-es", "_id" : "7" } }
{ "@timestamp" : "2021/04/20 23:49:30" ,"user.id":"jack","fail_num":"3"}
{ "create" : { "_index" : "test-es", "_id" : "8" } }
{ "@timestamp" : "2021/04/20 23:50:30" ,"user.id":"bill","fail_num":"9"}
{ "create" : { "_index" : "test-es", "_id" : "9" } }
{ "@timestamp" : "2021/04/20 23:52:30" ,"user.id":"jack","fail_num":"1"}
{ "create" : { "_index" : "test-es", "_id" : "10" } }
{ "@timestamp" : "2021/04/20 23:53:30" ,"user.id":"jack","fail_num":"1"}