携程酒店前端存在大量监控，但对于监控问题的排查成本，随着量级的增加而变得不可控。因此引入了智能预警归因系统，以数据池统一数据结构及标准；以预警规则池保证预警的准确性、低噪音；以算法模型进行根因分析，直接给出归因结果，从而提高整体排障效率。

一、背景

携程酒店大前端为了监测生产用户运行的稳定性和流畅度，对大量的系统指标、业务场景配置了监控。在运作的过程中我们发现，监控确实能发现很多的问题，但由此带来的排查成本随着量级的增加也变的不可控。

以系统指标监控说明：

目前约有30+类型，如页面慢加载、白屏等。每种异常监控都是独立的数据处理、预警机制、问题排查分析流程，互相之间没有关联。这一现状导致了一个个的数据孤岛，管理的高度碎片化，且无法复用，让维护和新增的成本较高。

同时，问题的原因不尽相同，排查链路也各自独立。举个例子：页面白屏异常上涨时，通过白屏的监控规则，触发预警后通知相关人员。排查人员从现有的白屏报表中进行badcase分析，排查锁定初步原因后，需要跨多个报表进行交叉验证，直至找到根本原因，整个过程中会耗费大量人力和时间成本。

在对页面白屏问题的深入剖析中，发现其根本原因往往与服务失败、服务耗时增长、内存溢出、增量数据拉取失败等因素密切相关。在现有的链路繁琐、异常之间没有关联性、分析效率低下、分析结果也不尽如人意。

基于目前情况，该如何找到解决方案呢？

经过对流程及问题的梳理，罗列了一些当前存在的核心痛点

数据角度：数据源分散，缺少关联性，报表过多，监控难维护&增加成本高

排查角度：现有流程链路长排查不方便，非常依赖人工定位，系统并不能很好的给出实际有问题点的方向。

针对上述问题，优化策略已明确成形，聚焦于几个核心要点：

数据整合：整合分散的数据源，确保数据结构的一致性与准确性，为后续分析奠定坚实基础。

统一预警规则：抽取预警规则库，形成统一的规则，减少重复编写预警流程和调整规则，提高预警的效率和准确性

算法归因分析：引入算法模型，深入挖掘不同数据与维度间的内在联系，精准归因问题根源，有效规避人工判断的主观性与不确定性，提高故障排查的效率。

简化流程：缩短故障排查路径，通过优化聚合排查报表，让问题定位更加直观快捷。

二、智能归因体系实现

2.1 整体方案

基于上述的优化方向，我们搭建了酒店前端智能预警归因系统，将多个数据预警孤岛串联起来，形成数据池。抽取统一且丰富预警规则，形成预警规则库，保证预警准确性。针对预警的异常，引进算法模型，实现算法模型归因分析，快速定位问题根源，并生成详尽的归因报告，给到开发明确排查方向。最终，将分析结果转化为清晰的告警通知邮件&排查报表，助力团队迅速响应，开展有效的故障排查与解决，大大提高了排查效率。

2.2 数据池

在整个体系中，搭建数据池是其重要的基石。数据池起到整合不同数据源的作用，将不同格式、维度的数据集中存储在同一个数据池中，对其定义统一的数据结构及标准，确保数据一致性和准确性。

拆解来看，将数据池划分为六大字段维度：数据类型、平台、指标、核心监控维度、基础字段以及业务特有字段。细致的数据维度分类不仅使得数据汇总更加直观，同时也大大提升了数据的结构化处理能力、降低后续使用成本。

数据池的数据，为以下3个流程，提供了核心的数据支持：

1）算法模型的基础输入：为算法模型提供必要的输入数据，确保模型运算数据的准确性和有效性。

2）预警规则的底表：作为预警系统的基础数据，为规则设定提供坚实的数据支撑，确保预警系统的精确性和可靠性。

3）监控预警邮件badcase的数据来源：针对监控预警邮件中的badcase，提供了详细且多维度的数据来源，以便进行深入的分析。

2.3 预警规则&加权

预警数据的准确性，是预警归因系统中的重要一环，如何让监控保证准确、不遗漏，且降低误报的概率呢？为了达到这个目标，把数据进行流量分级，且构建了多类预警规则，以权重加权的方式，进行预警判断，最后把多个规则的预警结果汇总起来，成为最终的结果。

首先说说流量分级和预警规则。

从数据池获取数据时，把数据本身的流量进行分级，分为高、中、低、仅关注四级。根据类型不同，并针对不同流量级别设置了合理的变化率阈值。流量越大，则对变化率越敏感。

权重计算公式：权重=流量分级系数*变化率

举个例子：数据变化率上升50%，通过规则，会计算出高级的权重值为max，中级的权重值为5，低级的权重值则为2，仅关注的权重值则为0。

在预警规则上，构建了四种不同维度的规则，以确保数据异常&变化的及时发现与处理：

1）单日同环比规则：通过对比当前数据与上周同日（同比）或相邻日期（环比）的数据，发现单日内的显著变化，如激增、骤减、新增或异常波动。

2）连续多日（周聚合）趋势波动规则：除了关注单日的数据变化外，还制定了周维度的数据趋势。通过对比每周的数据变化，能够更准确地评估数据的长期或持续性的趋势异常。这一预警规则不仅关注数据的变化幅度，还关注数据的变化方向和速度，从而更全面地把握数据的动态变化，确保不漏掉那些单日波动中被忽略的异常情况。

3）综合流量变动规则：该规则不仅考虑了数据本身的变化，还结合了与其相关指标/大盘流量，从而降低因用户流量放大、缩小而导致的数据变动预警噪音，确保预警的准确性。例如，针对页面白屏异常，监测异常率（异常数/页面流量）。

4）分位线预警规则：针对非报错类数据源，引入了分位线规则，以天为单位设定最优分位线作为基准，实时监测高于或低于该基准的数据占比变化及波动，确保数据的细微变化可以反馈出来。

基于以上四种预警规则，再结合数据本身的流量大小，设置了合理的变动权重。通过对权重进行加权计算后，能够精准得出每日的预警数据，确保系统与业务中的数据变动得到及时发现和处理。

在得到各规则的对比权重值后，同样根据流量分级进行分类加权，对加权结果进行阈值或权重的过滤，以确定在该规则下是否触发预警（具体参考“触发预警标准表”）。再根据不同的业务需求，叠加多个规则进行最终的数据预警，以确保预警的精准性，并有效降低预警的噪音。

2.4 模型归因

有了实际预警的类型后，基于预警结果及预警池中全量异常数据，将其作为算法模型的数据输入，经过不同的模型进行归因分析，最终获得归因结果值。

在实践中，考虑到对异常数据进行本身根因的分析、与其相关的其他问题导致情况、趋势问题等各类问题归因，使用了以下三种算法模型：

2.4.1 Adtributor算法

Adtributor算法是微软研究院于2014年提出的一种多维时间序列异常根因分析方法，在多维度复杂根因的场景下具有良好的可靠性。在任务中，首先对监控的各种关键性能指标(KPI)进行实时异常检测，当一个KPI发生异常时，想要解除异常，定位出其根因所在的位置是非常关键的一步。归因系统需要对检测到的异常指标进行维度分析和根因定位，而Adtributor算法非常适用于这个场景。

首先对异常指标进行维度拆分，维度拆分意在从预警结果的诸多维度中，分析出哪几个维度对一条预警造成的影响最大。

使用Adtributor算法来实现维度拆分主要包括以下几个步骤：

1）数据收集：以pv、uv作为参考指标KPI，将预警结果和预警池作为数据源，按维度构造原始数据集。

2）异常检测：采用ARMA时间序列模型对KPI进行实时预测，将预测值F和真实值A对比，判断KPI是否发生异常。

3）维度分析：Adtributor对异常KPI的所有维度和元素计算EP值和S值，从而定位到影响程度最大的维度。

下面对重要细节展开阐述：

数据收集

对于发生预警的数据，通过关联预警池，获取到每条预警在某个维度下，过去60天内每天的明细pv、uv值。

异常检测

ARMA（auto regressive moving average model，自回归移动平均）模型是研究时间序列的重要方法，它可以基于历史数据来预测未来的事情。

在每个维度下，基于过去59天的历史数据，使用ARMA模型推理得到当天的预测pv、uv值。将预测值与真实值进行对比，可以判断预警是否发生异常。

维度分析

将多维分析问题分解为多个单维分析问题，采用EP值和S值定位出每个维度下的异常元素集合，最后根据每个维度总的S值大小汇总输出相关维度集合。

1）对于异常KPI，计算所有维度下所有元素的真实值和预测值的差异，即S值(Surprise, 意外性)，将每一维度下的元素依据S值大小降序排列；

2）对于每一维度，从上到下依次对排序后的所有元素计算其变化在KPI变化总量中的占比，即元素对于KPI异常的解释能力EP值(Explanatory power, 解释能力)。

EP值

对于每一维度，如果元素的波动变化在异常KPI的波动变化中的占比越大，则认为元素越能解释KPI异常的发生。EP值(Explanatory power, 解释能力)用于衡量元素对异常的解释能力。EP值计算公式如下：

式中，A为真实值，F为ARMA时间序列模型正常预测值，下标i为维度、j为元素、m为异常指标。EP值可以为正、为负、大于100%，但是每个维度下的所有元素EP之和必须为100%。EP为正表示可能是异常维度，为负表示不是异常维度，大于100%表示与KPI异常有非常明显的正相关关系。

S值

如果KPI在某一维度下的真实值和预测值相差越大，则越有可能是异常维度。

KPI先验概率和后验概率的相似度可以采用相对熵(relative entropy)来衡量，进而判断维度是否具有意外性。JSD散度(Jensen-Shannnon divergence)是相对熵的一种变形，其对称性好、对于零值具有适应性、对相似度判别更加准确，这里基于JSD散度，得到S值(Surprise, 意外性)公式如下：

其中，预测概率或先验概率计算公式为：

真实概率或后验概率计算公式为：

维度的S值为维度下所有元素的S值之和，即：

在得到维度拆分的分析结果之后，还需要做深度根因的定位，根因定位意在从预警结果中，找出造成该预警的深度原因。例如：预警类型为页面白屏，而深度原因在于内存溢出，算法需要通过页面白屏与内存溢出之间的关联性，定位到深度原因。

通过计算预警结果所属类型的uv、pv行为，与其他深度类型uv、pv的相似度，来匹配深度原因。深度归因的实现是基于维度拆分的结果，具体来说：首先得到了一条告警影响最大的一个或者几个维度，然后只获取这些维度下的uv、pv指标作为特征向量，忽略其他影响不大的维度。对于所有的候选深度类型，也获取相同维度下的特征向量，然后计算向量间的余弦相似度，作为数据类型之间的关联性指标。相似度最接近的深度类型，即是该条预警关联性最高的深度原因。

2.4.2 Pearson相关系数（Pearson Correlation Coefficient）

考虑到通过 Adtributor算法定位深度原因，没有充分利用uv、pv的趋势变化，而事实上趋势的变化是预警判断时的重要依据，因此这里补充使用了另外一种基于趋势的相似度计算方法来定位预警的深度原因。

首先对预警明细表基于每个维度聚合，得到21天的pv、uv值作为特征表。然后对于每一条预警数据，以及待匹配的深度类型，都从特征表中获取相关特征，然后计算特征间的相似度。

由于主要考虑特征在趋势上相似性，因此选择Pearson相关系数（Pearson Correlation Coefficient）作为相似度指标。Pearson相关系数的绝对值越大，相关性越强，正数表示正相关，负数表示负相关。

总体相关系数公式如下：

其中 cov(X,Y)是X，Y的协方差，σX是X的标准差，σY是Y的标准差。

2.4.3 滑动T检验(Moving T test , MTT)

上述两种方法分别通过维度拆分、考虑趋势变化来定位预警的深度原因，已经比较周全，但仍存在问题，例如：开启的实验和页面的预警不能完全匹配。因此针对实验维度，启用了另外一种方案来解决，该方案通过匹配KPI的突变时刻与业务变更时间来实现。

具体来说，对于每条预警信息，首先获取当天分钟级别的pv、uv值，分别作为两组特征变量。对于每一组特征变量，使用滑动T检验(Moving T test , MTT)算法来定位发生突变的时刻。

滑动t检验是通过考察两组样本平均值的差异是否显著来检验突变。其基本思想是把序列中两段子序列均值有无显著差异看作来自两个总体均值有无显著差异的问题来检验。如果两段子序列的均值差异超过了一定的显著性水平，则可以认为有突变发生。

找到突变时刻后，可以将其与业务变更时间点进行匹配。若在时间范围内匹配成功，则数据变化可能与该业务变更有一定关联。如：结合了AB实验的数据，获取了所有AB实验流量开启、分流结果等的操作信息。若数据突变点前10分钟内，预警页面有相关的实验操作变更，则输出相应的实验归因数据。

2.4.4 归因结果聚合输出

在得到上边四个算法的结果后，按照既定的根因分类，根据根因实际情况，使用单个模型或多个模型的EP值结果限制卡点，进行归因结果聚合。

接下来，拆解这些根因的实际算法使用考量。

有了归因结果后，最终会以预警邮件或消息的形式发送给相关开发，并以监控报表的形式，来展示多维度的分布数据和异常明细，以提高整体排障效率。

看下实际案例：

案例1：6月9日，某详情页白屏上升，归因到代码报错升高导致

该日，通过多天的同环比规则权重叠加，监控出该页面白屏上升，报错率从0.22%上升至0.38%。

通过算法归因结果输出：锁定了操作系统、版本及频道；且深度归因发现，该类报错，是由于底层代码报错升高导致，两者间的关联度为97%。

归因结果给到开发有指向性的排查方向，提高排障效率。

案例2：5月21日，某页面图片慢加载上升，归因到与业务实验开启有关

该日，通过多天的同环比规则阈值限制，监控出该页面图片慢加载上升，报错率从24%上升至70%。

通过算法归因结果输出，该异常升高与平台、系统、及实验开启有关。

归因结果直接定位到了实验，精确到影响该异常的需求改动及关系方，以更好的评估新需求对系统性能是否带来影响。

三、阶段成果&后续规划

3.1 阶段成果

1）预警的准确性升高：老版监控的准确度约为60%，会有数据正常波动的场景也误触预警的情况；新版预警归因系统的准确率约为89%，有比较明显的改善。

2）从归因结果提供、排查报表数据整合、排查链路缩减三个方面来看，整体排查时间缩短约40%。

3）数据池中接入40+的数据类型。

4）已有19个传统预警、资源消耗监控，接入到新版智能预警归因系统中。

5）新版归因系统已发现问题约70+个，其中图片相关问题20+、页面慢加载问题10+、资源消耗问题7个……。预警后系统能直接找到影响的根本原因，如：内存上涨与图片size变大有关，流量上涨与服务调用次数变多有关；异常变化与实验开启有关。

6）该系统降低了不同数据源增加监控的开发成本。

3.2 后续规划

作者简介

SunnyZhou，携程资深测试开发工程师，专注于数据应用，以数据维度保障质量。

zw_jin，携程算法工程师，关注自然语言处理算法、大模型AIGC。

来源-微信公众号:携程技术

出处:https://mp.weixin.qq.com/s/Bs72Ghk_K9sqihzkZxSvqA