如何使用下探分析定位多维指标异常根因

使用场景

很多时序指标可以分解为若干个维度，每一个维度都具有不同的值域。例如网站的访问流量可以按照流量的来源省份分解，如分解为来自河南的访问流量和来自广东的访问流量等等；也可以按照流量的来源渠道分解，如分解为来自 PC 端的流量和来自移动端的流量。也可以按照多个维度的组合对时序指标进行分解，如来自河南的移动端的流量和来自广东的 PC 端的流量等等。如果时序指标可以划分成 n 各维度 dim₁, dim₂, ... , dim_n, 每个维度分别有 m₁, m₂, ... , m_n 个可选值。那么时序指标可以分解为 m₁ x m₂ x ... x m_n 个最细粒度的子时序指标。以访问流量举例，省份维度有 33 个可选值，渠道维度有 2 个可选值，那么总计有 66 个子时序指标。全局的指标是这些子时序指标聚合而成的。如果时序指标可以分解成很多维度，或者某些维度的可选值有很多，那么会有很多子指标序列。全局序列的异常变动往往是由若干个子序列的异常变动导致的。如果我们分别对每一子序列都配置一个异常检测任务，那么这些任务的配置量和维护成本都会很高。往往我们都只对若干聚合后的关键指标配置异常检测任务，如监控网站访问的总流量（不区分其各个维度）。这种情况下如果总流量检测到异常，由于其维度组合数量很多，我们很难人工判断到底是哪些省份，或者是哪些渠道，或者是哪些省份的哪些渠道访问流量异常导致了全局的流量异常。为了处理这种全局指标出现异常时，怎样快速定位异常维度根因的问题，我们上线了下探分析功能，帮助您自动定位多维指标场景的异常根因，缩小故障排查范围。样例总览图如下

使用案例

下面我们介绍如何使用日志服务提供的智能巡检服务和下探分析服务，对时序指标的异常变动进行多维指标的根因下探。智能巡检任务和下探分析任务的详细配置请参考官方帮助文档。我们案例中使用的数据包括三个维度，attr_a，attr_b 和 attr_c，每个维度有 5 个可选值，即有 125 个最细粒度的子指标序列。

智能巡检任务配置

首先我们使用智能巡检任务对指标进行异常检测，由于我们后续使用下探任务进行多维度的根因定位，因此我们只需要对总的序列配置异常检测任务即可。其中主要配置步骤是通过 SQL 构造待检测的指标序列，SQL 需要返回时间列、实体列和指标列，以便智能巡检任务可以使用这些列构造指标序列

从构造指标序列的 SQL 中我们直接讲各个维度组合的子序列的指标聚合，即仅对总指标序列进行异常检测。其他参数配置参考智能巡检任务帮助文档。

后续的下探分析任务使用智能巡检的检测结果作为异常事件触发多维指标的根因定位。智能巡检的检测结果写入到指定的 internal-ml-log 日志库中。检测结果的  json 形式大致如下，我们对构造异常事件所需的字段简要介绍一下

{
"__tag__:__data_type__": "anomaly_detect",
"__tag__:__instance_name__": "29030-f13218bd704462b86a8b64e27881fa32",
"__tag__:__job_name__": "etl-1681354396022-265300",
"__tag__:__model_name__": "13fd1a10d5921e99bd06b81590017ed6",
"__tag__:__schedule_id__": "f13218bd704462b86a8b64e27881fa32",
"algo_type": "supervised_anomaly_detection",
"entity": {
"entity": "artificial"  },
"meta": {
"project_name": "sls-ml-demo",
"logstore_name": "artificial-series",
"topic": ""  },
"result": {
"dim_name": "metric",
"score": "0.0012267196",
"anomaly_type": "None",
"is_anomaly": false,
"value": 3244.0964077708954  },
"version": "v0.3"}

进入配置的智能巡检任务的仪表盘页面，我们可视化的查看检测到的异常事件（异常分数 result.score 大于设置的阈值的事件），如下所示智能巡检任务检查到若干指标的异常变动

检测到异常时，我们一般会参考其他的系统指标和服务的运行日志等等，通过各种线索判断系统是否出现异常、确定异常的根因。在复杂系统中这个根因定位过程缓慢繁琐，如果有方法可以自动的缩小异常的排查范围，那么将有效的提高对于服务的运维能力。如果像案例中的检测的指标可以分解为多个维度的子指标序列，那么我们可以尝试使用下探分析任务确定导致异常的根因维度。

下探分析任务配置

进入日志服务智能异常分析的下探分析页面，点击右上方的立即创建创建下探分析作业。

数据配置

进入作业配置，配置作业名称后进入数据配置页面。数据配置包括异常事件源配置和多维指标序列配置。下探分析作业统一使用 SQL 查询语句从日志库中获取这两类数据。

多维指标序列配置

与智能巡检任务配置类似，我们首先需要设置多维指标序列数据源的 project、日志库。之后我们配置 SQL 获取最细粒度的维度组合及其每一时刻的指标值。即 SQL 的查询结果列包含三个部分：时间列、维度列和指标列，通过 SQL 下探分析任务可以获知某个维度组合在某个时间点的取值是多少。如下所示

相比智能巡检获取全局指标序列的 SQL，下探分析使用的 SQL 显式的获取了各个维度组合序列。例如数据预览中的第一行表示 “满足 attr_a=a5 且 attr_b=b1 且 attr_c=c4 的指标在 2023-04-14 14:05:00（时间戳 1681452300）的取值是 19.665”。SQL 配置完成后，在数据预览框下方配置哪一列是时间列，哪些列是维度列，哪些列是指标列。除此以外，还需要配置 SQL 的调度粒度，由于在我们案例中数据点每隔5分钟采样一次，所以我们配置粒度为300秒（5分钟）。这样下探分析任务会每隔5分钟运行一次配置的 SQL 获取新的多维指标。建议在 SQL 中对待分析的序列按照一定的时间窗口进行聚合，如3分钟，5分钟等，粒度设置为时间窗口的长度即可。

异常事件源配置

在完成配置多维指标序列后，我们需要对异常事件源进行配置。下探分析任务从事件源获知什么时刻出现了异常事件，然后触发对于异常事件的多维指标异常根因定位。点击下方的添加事件配置创建事件源。异常事件使用 SQL 语句从日志库中获取的，我们首先需要配置 project 和日志库。由于我们使用智能巡检任务的检测结果，所以我们配置 project 为巡检任务使用的 project，日志库为保存检测结果的 internal-ml-log 日志库。之后我们通过 SQL 获取检测到的异常事件时间和异常，如下

*and __tag__:__job_name__: etl-1681354396022-265300and __tag__:__data_type__: anomaly_detect |selecttime, IF(score >0.8,true,false)as status
FROM(select    __time__ astime,    cast(json_extract(result,'$.score')asdouble)as score
FROM log
limit all
)limit1000000

在查询分析语句中我们使用 __tag__:__job_name__ 和 __tag__:__data_type__ 字段过滤出配置的智能巡检作业的异常检测结果。在 SQL 部分获取异常的发生事件和异常分数（result.score），只有当异常分数大于 0.8 认为检测到的异常是真实的异常。SQL 的结果列需要至少包含两列，时间列和状态列，只有当状态列取值为 true 或者为正数时，认为在对应时间确实有异常发生。具体配置如下

如果有多个事件源，也可以通过点击添加事件配置按键继续添加，配置完成后也可以对事件源进行热更新。

算法配置

完成数据配置后点击下一步进入算法配置页面，算法配置项的解释可以参考官方帮助文档。需要关注的是数据延迟配置项，表示下探分析任务在读取数据时需要等待的时间，以秒为单位。如果配置60秒延迟，那么任务需要等到 12:06 再读取 12:00 ~ 12:05 的数据时（延迟一分钟）。这是因为事件源中的异常事件数据写入到日志库中可能有一定的延迟，为了保证下探任务读到异常事件，需要设置其数据延迟大于日志事件的写入延迟。由于智能巡检任务从检测到异常事件到把检测结果写入到日志库大约有60秒的延迟，因此我们设置下探分析的数据延迟为90秒。配置如下

之后点击下方的完成按键就开始运行下探分析任务了。

下探分析结果说明

点击刚刚配置的下探分析作业，进入分析结果仪表盘。在页面上方选择适当的时间范围、事件源名称和事件发生的时间，就会在下方显示对于这个异常事件的根因定位结果。如果事件时间右侧显示绿色标签 “状态: 成功”，表示下探分析作业定位到了对应的异常事件的根因；如果显示红色标签 “状态: 失败”，表示没有定位到对应异常事件的根因，如下

如果定位到根因，那么在页面的下方会显示所有可能得根因，以及每一个根因导致异常事件的可能性。通过勾选这些根因，我们可以查看这些根因对于原始序列的影响

• 正向显示：显示包含这些根因维度的子序列聚合后的序列的形态。如下，可以看到包含异常维度的序列在异常事件发生的时刻也有形态上的异常变化，说明勾选的维度可能确实是异常事件的根因。
• 反向显示：显示不包含这些根因维度的子序列聚合后的序列的形态。如下，可以看到不包含异常维度的序列在异常事件发生的时刻形态正常、无明显异动，说明勾选的维度可能确实是异常事件的根因。

如果想要增删改事件源，可以点击上方的事件数据管理，进入事件源管理页面。