1. 本文概述
智能监控通常包括了俩个方面： 检测 告警。目前的智能监控一般在检测层都实现了智能化（统计分析算法、机器学习算法等方案），例如3-sigma，EWMA，决策树，xgboost，DNN等。 但目前告警则更多的聚焦在告警合并（或者叫告警收敛）上， 而对于告警分级，目前常用的方案仍然是运维人员预先设定分级的方案。
本文则是对清华大学在2020年发表的论文：Automatically and Adaptively Identifying Severe Alerts for Online Service Systems进行的总结和梳理，这篇论文主要就是讲解了如何进行自适应的告警分级方案。
该论文的核心思想则是：利用历史告警的处理记录来做标注，利用多特征融合的方法进行排序模型的训练，对线上实时到达的告警流进行排序，以排序结果作为严重性的定级结果。把本来告警分级的问题转化成了严重性排序的问题，这样运维人员拿到排序后的问题，可以优先处理排在前面的告警。
2. 论文摘要：
在大型在线服务系统中，为了提高服务质量，工程师需要收集各种监控指标数据并编写许多规则来进行触发警报。但是，在实际的应用过程中，很容易形成超过工程师们能处理掉的告警数量–比如告警风暴等。因此，工程师则会事先定义一些告警等级，例如最严重级别为p0。 这样，运维工程师可以专注于处理优先级最高的警报（即，严重警报）。但是，由于在线业务是复杂且动态变化的，预先设定的告警等级有时并不能反映问题真正的严重程度，这就导致这种基于规则定义告警等级的方法会错过严重警报或浪费运维人员很多精力在处理不严重的告警中。本文提出了AlertRank，这是一种自动且自适应识别严重告警的框架。特别的是，AlertRank可以提取一组功能强大且可解释强的特征（包括：文本和时间特征，单变量和监控指标的多元异常特征），同时采用XGBoost排名算法在所有传入的警报识别出严重的告警警报，并使用新颖的方法来进行训练和测试数据样本的打标工作。基于头部银行提供的数据集进行验证，结果表明AlertRank是有效的且平均F1-score达到0.89。来自实践的反馈也表明AlertRank可以大大节省运维工程师的人力成本。
3. 背景描述：
为了保证在线服务的高质量，高稳定性，我们需要做服务的各种指标进行监控。 当指标发生异常时，则需要快速准确的发出告警，通知运维人员。但在真实的应用中，往往会产生大量的告警或警报给运维人员，导致运维人员根本无力去处理。 上图展示了某银行每天产生的告警数量。可以看到，基本在千到万级别/天。因此，为了方便运维人员快速的去解决最严重的问题，监控系统往往支持预先设定告警模版和告警等级。以CPU监控为例，往往按照CPU值来设定阈值，利用率超过95%是P1，90%是P2，利用率超过80%是P3；以日志监控为力，则一般是提取日志的关键字，如果有fatal就是P1，fail就是P2，有warning就是P3。
4. 目前常见的解决方案：
工业界实践中由于告警很多，往往会事先对各类告警进行分级。而目前告警定级通常基于手工规则的告警，比如P0是严重，P1是错误，P2是警告等。但是如何按统一的标准去分级？常见的定级规则：
以CPU监控为例，往往按照CPU值来设定阈值，利用率超过95%是P1，90%是P2，利用率超过80%是P3；以日志监控为力，则一般是提取日志的关键字，如果有fatal就是P1，fail就是P2，有warning就是P3。
4.1. 目前方案存在的问题：
由于业务系统过于复杂，且动态变化，预先设定的告警等级并不每次都能很准确的描述其发生问题时的真实等级，这是由于：
- 告警类型众多
- 随着业务的变化，告警类型发生变化，一些新的告警加入到了业务系统，但是并没有针对这些进行分级
- 不同的运维工程师分级标准不一致
这会导致俩个问题：
- 真实严重的告警可能遗漏掉 – – 对应真实的严重告警召回率低
- 运维工程师优先处理的“严重”告警可能其实并不严重 – – 对应处理的严重告警准确率低
为了佐证，这里论文给出了一个真实的案例：
- 10:14发生了一个P2级别的告警，告警内容是反应时间增加到了500ms。 但由于这个是P2级别的，运维工程师在忙着处理P1级别的告警，没有对这个告警及时响应。
- 10:45，有用户的投诉进来，这时候发现有多个指标出现了异常。 这些多个指标异常组合起来本应该反应出是严重的告警级别P1，但是由于没有预先设定的规则，因此只是发出了P2告警。
- 这个案例说明了应该考虑多个指标的组合来评定一个告警的级别。
5. 本文提出的解决方案：
5.1. 框架简述
整体的AlertRank分为离线和在线俩部分。 离线部分的主要目的是迭代训练出可用的排序模型。 在线部分的数据处理部分和离线类似，在排序部分则可以加载离线训练好的排序模型进行排序，按照告警等级排序输出告警给运维人员。
5.1.1. 离线部分：
- 数据输入：输入的数据主要是历史上发生的告警和告警对应的KPI数据。
- 预处理：俩部分数据都需进行一定的预处理。
- 特征提取：通过对告警内容文本内容的提取，可以获得告警本文特征以及告警时间特征。 再结合告警对应的KPI以及关联的KPI数据，则可以从KPI中提取出需要的特征。
- 排序模型：将这些特征组合成特征向量，可以用于排序模型的输入。 在该论文中，排序模型选择的是XGBoost排序算法。
- 标签这里每个告警的严重等级标签则来源于从之前告警处理记录中提取得来。
5.1.2. 在线部分：
输入的数据则是多条实时的告警记录以及对应告警的KPI数据。 经过特征工程后，特征向量输入到离线训练好的排序模型算法，输出对应告警的告警严重性分数。 针对告警严重性分数设定一个阈值，超过阈值则认为是严重的告警。 这里的阈值则是从离线数据中训练调参得到。
5.1.3. 模型优化：
模型定期的进行增量式离线优化，以应对动态变化的业务系统。
5.2. 特征工程：
5.2.1. 告警预处理：
- 分词： 去除一些通用的标点符号，连接词等。
- 解析：解析则是解析文本， 这里文中采用了FT-tree算法进行文本解析，
5.2.2. 文本特征：
通过预处理后，半结构化的告警文本转化为了标准化的模版。 可以从中提取告警主题（这里文中采用了LDA，这种常用的主题提取模型）， 和反应告警等级的熵（文中采用了IDF进行词频重要性统计）
5.2.3. 时间特征：
告警的频率，周期特征，告警数量，同一个告警间隔时间以及其他特征（包括但不限于：人工定义的告警等级，告警时间，告警类型等）。
5.2.4. 时序特征：
很多告警都是由时间序列异常触发的，结合时间序列特征，可以更好的去定义告警等级。 该论文中强调了不同时间序列可能存在一定的关联性（比如底层机器指标和业务指标之间存在关联，业务指标之间也存在一定的关联性，如下图a所示），
因此问题转化为了如何挖掘这些相关联特征？
这里文中采用了最新的基于LSTM模型的多元时间序列异常检测算法来提取多元时间序列特征。该模型详细内容可以参考论文“Detecting spacecraft anomalies using lstms and nonparametric dynamic thresholding”。
5.3. 排序模型
排序学习是一个有监督的机器学习过程，对每一个给定的查询－文档对，抽取特征，通过日志挖掘或者人工标注的方法获得真实数据标注。然后通过排序模型，使得输入能够和实际的数据相似。 常用的排序学习分为三种类型：PointWise，PairWise和ListWise。
Pointwise常用方法有McRank等，Pairwise有很多的实现，比如Ranking SVM，RankNet，Frank，RankBoost等， Listwise常用方法有AdaRank，SoftRank，LambdaMART等。对排序学习感兴趣的可以参考：
- https://medium.com/@nikhilbd/pointwise-vs-pairwise-vs-listwise-learning-to-rank-80a8fe8fadfd
- https://zhuanlan.zhihu.com/p/111636490
- https://zhuanlan.zhihu.com/p/26539920
这里论文是需要对每条进来的告警进行排序学习，属于PointWise类型。 同时论文中提到不仅希望得到告警的等级排序，同时还希望得到每个告警严重性的得分， 综合俩个因素，以及考虑到XGBoost pointwise 排序学习算法在业界的其他应用中效果也很不错，因此论文中采用了XGBoost pointwise 排序学习算法作为排序模型。
6. 效果评估：
6.1. 数据集
为了评估AlertRank整体框架效果，文中采用了3组从业界头部银行收集来的真实业务数据。如上表所示，每组数据集的时间跨度为6个月。每组数据集的告警数量在40万量级左右，同时对里面的每条告警是否为严重告警进行了标注。严重告警：告警总量大概在1:50左右。
同时，论文将每组数据集的前5个月作为训练数据集，将最后一个月作为测试数据集。
6.2. 模型评估
模型评估该文则是从几个典型的角度去对比分析，比如AlertRank是否比目前其他方法好？AlertRank中的特征工程是否有效？AlertRank中的排序学习模型表现如何？
6.2.1. AlertRank 识别严重告警的能力如何？
为了对比AlertRank的能力，这里文中对比了俩个baseline的方法： 基于规则的方法和Bug-KNN的方法。
基于规则的方法： 正如前面介绍，目前业界常见的选择就是人工事先定义不同告警的告警等级， 如P1、P2、P3。运维人员往往会优先处理P1级别的。
Bug-KNN的方法：这个主要是利用KNN，在历史的告警以及处理报告中，去找出和当前告警类似的告警出来进行定级。
对比的结果如下，可以看到，在三个数据集中，AlertRank的准确率，召回率，F1-Score都远远好于另外俩个baseline的方法。
6.2.2. 不同特征对模型整体的贡献如何？
下表对比了全部特征，只有告警特征，只有时序数据特征三种情况各自的表现，可以看到结合了告警和时间序列俩大类的特征组合，效果要更好。笔者认为这个结论其实也是很显然的，毕竟你的特征数量更多，而且都是相关联的一些特征组合，组合起来效果肯定优于单独的。
从这个表里可以看到的另外一点是只有告警特征的模型表现是要远远优于只有时间序列特征的。
6.2.3. AlertRank方法和其他分类型方法的对比？
此外，AlertRank的一大创新点也在于将原本告警分级的分类问题转换为了排序学习问题。 在文中作者也对比了AlertRank和业界常用的分类方法模型的效果对比，AlertRank是要更好的。
当然，文中还有一些其他的评估讨论，感兴趣的可以研读下原文。
7. 结论
通过对历史告警的处理记录来做标注，利用多特征融合的方法进行排序模型的训练，对线上实时到达的告警流进行排序，以排序结果作为严重性的定级结果。把本来告警分级的问题转化成了严重性排序的问题，这样运维人员拿到排序后的问题，可以优先处理排在前面的告警。整体模型评估也是远远优于目前业界常用的几种方法。
回归到腾讯云监控AIOps项目， 这俩年我们一直在推动智能监控应用场景在腾讯云内外部的应用。 在这个过程中，我们更多的聚焦在了异常检测和告警收敛这俩块内容，而忽视了告警分级上优化的可能。 该论文有效的帮助我们去进一步梳理智能监控场景中值得优化的点，从而进一步去提升整个智能监控的效果，发挥智能监控更大的价值。
Reference：
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9155219&tag=1
https://mp.weixin.qq.com/s/R91THnczdrUIFqyIzoo8yg
https://arxiv.org/abs/1802.04431
https://medium.com/@nikhilbd/pointwise-vs-pairwise-vs-listwise-learning-to-rank-80a8fe8fadfd
https://zhuanlan.zhihu.com/p/111636490
https://zhuanlan.zhihu.com/p/26539920
