如何将多条告警关联在一起进行展示和分析，以及如何将多条有联系的告警转换成一条或少量几条包含更多故障信息的告警，以此达到降低活动告警的种类和数目，减轻运维人员的工作压力，提高故障精确定位效率，是一个很值得研究的课题。
内容大纲：
- 背景
- 定义
- 竞品公司的告警关联模块
- 我们怎么做
- 案例分享
- 参考文献链接
1. 背景
在实际运维过程中，为了避免异常的遗漏，业务运维人员经常针对不同的业务，设定大量不同的监控指标和告警规则。在这些告警信息中存在着很多相关联的告警规则，或强相关的业务指标等。换句话说，一个业务模块发生了故障，可能会引起多个模块触发告警。
因此，在每天产生的大量告警信息中，存在着很大的冗余信息。真正有效的告警信息，很有可能就被隐藏在这众多冗余的信息中，从而导致业务运维人员忽略掉了有效的告警信息，导致业务故障不能够及时的去处理。
如何将多条告警关联在一起进行展示和分析，以及如何将多条有联系的告警转换成一条或少量几条包含更多故障信息的告警，以此达到降低活动告警的种类和数目，减轻运维人员的工作压力，提高故障精确定位效率，是一个很值得研究的课题。
2. 定义
2.1. 告警数据一般可以分为指标型和事件型（Metrics and Events）俩种数据类型。
Metrics
如上图所示，指标型数据又可以分为业务指标和资源指标。
指标型数据示例（某机器的内存时序数据）：
Events
除了可以或多或少连续收集的指标之外，某些监视系统还可以捕获事件：不连续的，不经常发生的事件，这些事件为理解系统行为的变化提供了关键的环境。 比如：
（1）更改：代码发布，构建和构建失败
（2）警报：主要监视系统或集成的第三方工具生成的通知
（3）扩展事件：添加或减去主机或容器
事件型数据示例（AMP的一条历史告警信息）：
事件型数据往往可以包含更多的字段信息，里面的内容可能是结构化的，也可能是半结构化和非结构化的。通过对告警事件的关联分析，往往可以发现系统故障的原因，分析出到底是什么导致了异常。
2.2. 告警关联包括告警关联展示，告警关联搜索，告警合并以及告警摘要。
2.2.1. 告警关联展示是通过把异常里的相关联/相似的告警记录（可能是相似的时间序列，或者相似的告警事件记录），通过合并或者聚类的方法，给放在一起展示。给运维人员一个多视图的关联数据，便于去找出问题的故障根因和更快的解决相类似的故障。
2.2.2. 告警关联搜索是通过一段有异常的时间序列，去搜索到与之相类似的时间序列。范围不局限在异常告警里。这样，通过关联到的结果，可以更好的挖掘与之关联的所有业务指标，从而更好的挖掘出异常根因。搜索范围不局限在异常告警的原因在于，有些与之相类似的上下游业务时间序列，检测结果并不一定是一场（不同业务设定阈值不同，接入的检测算法也不相同，等）。
2.2.3. 告警合并：告警合并的理解很简单，一般就是指在某个确定的时间窗内，把多条相似的告警，合并为一条。这样做可以大大减少告警的数量，但是对于发现问题解决问题的效率，没有本质的提升。
2.2.4. 告警摘要：告警摘要相比告警合并，则显得更加智能一些。 在合并的过程中，通过一些字段提取，相似性计算以及聚类等操作，从多条相似，或者关联的告警记录中，提取成一条精简的告警记录信息。一方面告警数量可以从多条削减为1条，另一方面，告警记录的内容经过加工，更利于运维人员进行故障查找和修复。
3.竞品公司的告警关联模块：
3.1. Data-dog：
Data-dog的关联分析模块，主要目的是想通过关联来做根因分析和定位。从他们的博客可以看到，任何一段时间序列，选定对应的时间段后，Data-dog可以搜索与之相关联的指标数据，也可以查看与对应时间序列相关的主机信息，日志及其他信息。
通过对目标的时间序列段进行关联搜索，可以展示出与之相类似的所有指标。
通过相关的业务指标分析，可以辅助分析出出现异常指标的上下游业务，从而更好更快的去定位的问题。
更多：https://www.datadoghq.com/blog/metric-correlations/
###
3.2. 百度：
3.2.1. 简单的报警合并:
选择合适的字段，直接将字段进行groupby，多条合并为一条记录。
具体细节为：一个报警产生以后，我们先把这个报警插入一个发送等待队列而非立即发送。每一个报警策略都有一个在等待队列里的最长存留时间，换言之，是这条报警可以容忍的 最长延迟发送时间 。报警产生后先插入等待队列里面去，在队列里等进行延迟计时，当达到了能够容忍的延迟时间以后，我们在等待队列中找到可以和该报警一起合并发送的报警，根据实际的合并维度渲染成不同的报警短信内容，然后合并成一条报警短信发送。
在下面的例子里，A，B，C代表了3个不同的模块，A模块上配置了两条报警策略分别为rule1，rule2，B模块上配置了rule3，C模块上配置了rule4，红色的报警A:rule1即将到达最长存留时间，按照合并策略，黄色的报警可以一起合并为一条发送，这样实际的报警信息中包含了三条报警。
3.2.2. 关联策略的报警合并：
某个模块的出现问题的时候，往往会引发上游或者下游模块也一并报警。假设模块A调用了模块B，当模块B出现问题的时候，很显然模块A和模块B都会产生报警。为了解决这个问题，我们尝试从 历史报警数据中挖掘关联的报警策略列表：
常用的频繁项集挖掘方法有：Apriori，Fp-Growth，Eclat等。
通过对历史告警数据的挖掘，我们可以建立关联规则库，这样发生告警时，可以去关联规则库去匹配对应的关联项。
3.3. Prometheus 的告警收敛功能
Pometheus成功的把一条告警发给了Altermanager，而Altermanager并不是简简单单的直接发送出去，这样就会导致告警信息过多，重要告警被淹没。所以需要对告警做合理的收敛
告警收敛手段：
分组（group）：将类似性质的警报分类为单个通知，类似于百度的告警合并
（1）减少报警消息的数量
（2）同类告警聚合帮助运维排查问题
抑制（Inhibition）：当警报发出后，停止重复发送由此警报引发的其他警报
静默（Silences）：是一种简单的特定时间静音提醒的机制
4. 我们怎么做：
最后，再简单介绍下我们在告警关联这个场景下的思考。
从数据类型上分，告警信息可以分为时间序列和事件。对应的关联分析可以分为基于时间序列的告警关联，基于事件的告警关联，以及事件和时间序列的联动分析。
4.1. 基于时间序列相似性的关联展示
我们通过对monitor单视图下的所有异常时间序列做聚类，将相似的时间序列放在一起展示。目前已经实现了同一视图下的所有时间序列异常做关联展示。
对于未来的跨视图时间序列关联，一方面可以继续沿用现有的逻辑。另外，也可以通过挖掘历史告警数据，结合关联规则库的方法，以提高在线关联查找的效率。
4.2. 基于事件相似的关联展示和告警摘要：
对于相同/相似的告警记录，仅仅是简单的进行合并，可以通过groupby的方法获得。但这样只是从数量上减少了告警数量，对于内容质量的提升并没有太大。
我们的想法是通过挖掘和提取告警记录中一些非结构化的字段内容 对告警维度进行一定的扩展，从而获得更多的告警信息，整理总结成一个告警摘要的形式发送给业务运维人员，辅助他们进行故障的定位和解决。
4.3. 事件和时间序列的联动分析：
从指标的时间序列探测到异常，往往也对应着一条告警记录。可以选择合适的id，将事件记录和时间序列关联起来，这样可以给运维人员提供更多的信息。
5. 案例分享：
5.1. 异常的时间序列关联展示（腾讯-云监控）
在告警记录里面，将相似得告警记录进行聚类，放在一起展示。
以monitor时间序列关联为例，将在monitor同一视图下的异常时间序列进行聚类，一起展示的效果图：
5.2. 通过时间序列的关联搜索，进行辅助的根因分析（Datadog）
在可能包含数百个服务以及数千个主机和容器的应用程序体系结构中，可能需要花费数小时的时间才能找出问题的根本原因。 Datadog的“关联”视图通过隔离相关的指标来确定性能或可用性的任何变化，从而缩小了调查的范围，并揭示了潜在的根本原因。 例如，当完成的检出次数意外下降时，“关联”视图会自动识别哪些服务或基础结构系统可能是导致中断的原因。 然后，Datadog会显示来自每个系统的相关指标。 借助相关性，运维人员可以将问题的源头归零，而不必依靠猜测或费时的，可能的根本原因的广泛探索。
来自datadog：https://www.datadoghq.com/solutions/machine-learning/
6. 参考文献链接
1. https://www.datadoghq.com/blog/metric-correlations/
2. https://www.datadoghq.com/solutions/machine-learning/
3. https://mp.weixin.qq.com/s/9IZbmulUA18OCZ-ECSNSUQ
4. https://mp.weixin.qq.com/s/vODNelOyTwyciI-6sYBUtA
5. https://www.cnblogs.com/xiangsikai/p/11289937.html
6. https://zhuanlan.zhihu.com/p/30628883
