《Elastic Stack 实战手册》——三、产品能力——3.5 进阶篇——3.5.2.Kibana的Alert(1) https://developer.aliyun.com/article/1228799
Alert Instances 的概念和抑制重复告警
检查一个 condition 条件时，Alert 可能会识别该条件的多次出现。每出现一次符合condition 条件的情况，Kibana 就生成一个 Alert Instances，即警报实例。那么 Kibana 分别跟踪每个警报实例，并对每个实例采取行动。
重复告警
以下面的图示例，将每个平均 CPU 为> 0.9 的服务器作为 Alert Instance 进行跟踪。然后将每个超过阈值的服务器都将发送单独的电子邮件。
那就会带来一个问题，当 Alert Instances 过多的时候，就会造成大量通知重复发送，即Alert Noise 的现象。
比如一个警报每分钟监控三个服务器的 CPU 使用情况 > 0.9，就发送邮件通知工作人员:
l 第一分钟：服务器 X123 的 CPU > 0.9
l 其中一封邮件发送通知工作人员服务器 X123 的 CPU 过高。
l 第二分钟：X123 和 Y456 的 CPU > 0.9
l 发送了两封邮件，一封是关于 X123 的，一封是关于Y456的。
l 第三分钟：X123, Y456, Z789 的 CPU > 0.9
l 发送了三封邮件，分别是 X123，Y456，Z789。
在上面的例子中，对于相同的条件，在3分钟的时间内，向服务器 X123 发送了3封邮件。
抑制重复告警
Kibana 针对这个情况做了抑制重复通知的优化，主要是通过设置通知间隔来抑制重复多余的告警。比如在上面的例子中，将警报重新通知间隔设置为5分钟，那么 Alert 发送通知的情况则如下：
l 第一分钟：服务器 X123 > 0.9
l 邮件发送报告服务器 X123 的 CPU 过高。
l 第二分钟：X123 和 Y456 > 0.9
l 邮件发送报告服务器 Y456 的 CPU 过高。
l 第三分钟：X123, Y456, Z789 > 0.9
l 邮件发送报告服务器 Z789 的 CPU 过高。
当然过了五分钟后，如果服务器 X123 > 0.9还是存在，那么继续会发送邮件，报告服务器 X123 的 CPU 过高。
Kibana Alert 的实现机制
Kibana Alert 将 Alert Check 的信息和 Action 的信息，持久化在 Elasticsearch 在后台执行。这有两个主要好处:
1、持久性：所有的任务相关的信息都存储在 Elasticsearch 中，所以如果 Kibana 重新启动，Alert 和 Action 将从它们停止的地方恢复。
2、伸缩性：多个 Kibana 实例可以从 Elasticsearch 中读取和更新相同的任务队列，允许
Alert 和Action 跨实例分布。如果现有的 Alert 执行数量超出了现有的 Kibana 实例的容量上限，可以增加额外的 Kibana 实例。
Kibana 后台任务的执行机制
1、每隔3秒轮循 Elasticsearch 任务索引以查找过期任务；
2、任务执行后在 Elasticsearch 索引中更新，使用乐观并发控制来防止冲突；
3、任务在 Kibana 服务器上运行。每个 Kibana 实例最多可以运行 10 个并发任务，因此每个间隔最多可以声明 10 个任务；
4、对于重复后台检查的 Alert，任务完成后将按照检查间隔再次调度。
因为每3秒轮询一次任务，并且每个 Kibana 实例只能同时运行10个任务，所以 Alert 和
Action 任务可能会在以下情况延迟运行：
1、警报使用较小的检查间隔。最低间隔时间可能是 3 秒，但建议间隔时间为 30 秒或更高。
2、许多警报或操作必须同时运行。在这种情况下，挂起的任务将在 Elasticsearch 中排队，并且每隔 3 秒从队列中取出 10 个任务。
3、长时间运行的任务占用槽位的时间较长，留给其他任务的槽位较少。
《Elastic Stack 实战手册》——三、产品能力——3.5 进阶篇——3.5.2.Kibana的Alert(3) https://developer.aliyun.com/article/1228796
