建设背景
近些年,苏宁一直基于云技术对外提供服务、产品、内容和应用。随着苏宁线上业务不断扩张,业务量不断上升,线上各系统间的交互关系也变得越来越复杂。目前线上运行的系统大约 5000+,服务有 15w+。
为了更有效的保障线上业务的正常运营,苏宁提出了从系统监控、问题定位、实时告警到决策分析、故障自愈的一站式解决方案,打造从“监”到“控”的全方位一体化的监控体系。同时,引入深度学习 AI 技术对监控数据进行知识图谱的构建和训练分析,更精准地分析出导致问题发生的根因,让业务人员及时了解到当前线上运营状况和可能产生的问题,并能预先采取有效的措施,保障业务的正常运营。
大规模时间序列分析与根因定位
业务背景
在传统监控中,面对海量运维监控数据,需要快速止损,但人肉监控(例如 ELK)不现实,决策时间往往是小时甚至天级别。对于异常点往往需要丰富的经验去识别,但是随着时间的推移,业务数据的特点会发生变化,因此过去的经验也需要与时俱进。我们期望使用 AI 异常检测的方式快速发现问题并且给出决策建议(分钟级)或提前规避故障,并且使用历史数据结合 AI 算法自动更新业务经验知识。
异常检测平台能力
异常检测平台主要由四大模块组成。
异常检测
使用深度学习技术获取模型概率密度及蒙特卡洛采样技术确定异常检测边界阈值,部分监控场景告警准确率高达 98.21%,帮助用户精准地发现问题。
指标预测
使用深度学习算法构建的模型为基学习器,结合 stacking 集成学习方式构建预测模型,利用最近 400 分钟的数据预测未来 20 分钟的指标趋势,提供各类指标预测功能,用户可以提前预知指标的趋势变化。
多维度分析
对于发生告警的可加性指标,以单维度指标为基础,使用类 HotSpot 家族的算法对异常数据进行分析,定位出主要的影响因素,帮助用户快速定位异常数据维度,大大提高工作效率。
自定义仪表盘
多种类型数据源接入配置:
支持用户任意指标的配置,提供统一的 SQL 语法作为指标计算表达式,让用户能够迅速上手配置基于不同数据源的指标。
支持饼图、折线图、柱状图、泳道图等十多种数据可视化展示。
自定义 Dashboard 可根据用户偏好定义不同的报表主题、维度展示、样式布局。
时序预测方法
1 DeepAR
DeepAR [1]是一种适用于时间序列预测的监督学习算法,该算法使用递归神经网络 (RNN) 生成点预测和概率预测。与自回归移动平均模型 (ARIMA) 或指数平滑法 (ES) (许多开源和商用软件包中都采用这两种技术进行预测) 等传统预测技术相比,DeepAR 预测算法可以提供更高的预测精度。
计数型数据预测公式
实数型数据预测公式
DeepAR 可以对相关的时间序列建立统一的预测模型,同时进行点预测和概率分布预测,冷启动预测,实现少量历史数据预测,适用于海量数据场景。
预测效果
2 MQ-RNN
主要思想是近期数据预测接下来某段时间的数据,模型训练和选择的训练时窗和预测时窗有关。比如,用 3 月的数据训练,预测 4 月的需求。
MQ-RNN[2]的模型结果类似 Sequence-to-Sequence,分成 Encoder 和 Decoder,只是 Decoder 不是一个 LSTM 的模型。Decoder 涉及两个 MLP (Multi-layer Perceptron)。 第一个 MLP,称为 global MLP,整合 encoder 输出的隐向量,外加未来的 features。第二个 MLP,称为 local MLP,参数在 horizon 上是共享的。Local MLP 输出对应 Quantiles 的预测值。比如 t+k 时间点对应的各个 quantiles 值。整体的模型架构及相关公式如下:
Global-MLP 公式
Local-MLP 公式
LOSS 函数
预测结果如下所示:其中,红色和绿色分别为 90%,10%分位数,黄色为预测中位数,蓝色为真实值。预测值基本接近于真实值。MQ-RNN 对于 DeepAR 有较大的改进,直接输出不同的 quantile 的预测值,目标函数改为 quantile loss,可以解决一下冷启动和大促的离群点的预测。但是 MQ-RNN 需要确定时间窗口。比如通常我们要预测下个月每一天的,我们会采用历史所有数据进行训练和验证。MQ-RNN 的训练数据可能固定使用一个月的,一个季度的或者一年的,这样的方式可以缩减训练时间,但是需要通过其它方式确定选取较优的训练时间窗口大小。
预测效果
3 MQ-CNN[2]
模型架构思想和 mqrnn 类似,encoder 改为 dilated cnn,每层 CNN 结构经过 dilated cnn 后使用 relu 进行非线性变换,在经过 1 个 1*1 CNN,得到每层的 skip 输出,将多层 CNN 堆叠起来形成深度网络,为了防止网络太深导致信息损失,每层的输出加上输入的残差,将所有层的 skip 拼接后经过 relu 后得到最终输出,可以使用更多的历史数据进行训练。整体的模型图如下所示:
整体看来,MQC 的 encoder 为 CNN,训练速度更快。通过 Dilated Conv 能使模型处理更大长度的输入数据。对率型数据预测效果没有计数型好。
预测效果
集成方法
单个预测模型在不同类型的数据上性能差异较大,DeepAR 模型对 rate 指标预测效果较好,但 count 指标预测效果较差,MQCNN 对 count 指标预测效果较好,但 rate 指标预测效果较差。集成模型的目标是结合各模型的优势,得到比单个模型更优、更鲁棒的结果。使用 FFNN(前馈神经网络)/XGB(xgboost)/RF(随机森林)/RR(岭回归)/简单加权平均(SWA)等作为 stacking meta learner,最终根据评估指标自动选择最优集成模型。
SWA 方法比较简单,只要计算出相应的权重。
XGB/RR/RF/FFNN 等方法则相对复杂一点,需要进行如下处理:
数据预处理:对deepar,mqrnn,mqcnn的预测结果进行标准化,使用(预测值-均值)/标准差的方法。实验表明,标准化后的集成效果好于非标准化的数据。
模型输入:deepar,mqrnn,mqcnn的预测结果,时间序列的特征(分钟,小时,星期几等),时间序列的编号等。
损失函数:均方差,并增加L2正则化,防止过拟合。
集成模型自动评估和选择:使用测试数据真实值与集成模型预测值的SMAPE作为评估指标。自动选取测试集上SMAPE值最小的模型作为最终的集成模型。
预测上下边界生成:使用集成模型的预测值及各基模型的标准差作参数,采样选取合适的分位数生成上下边界。
我们通过如下预测结果可知,黑色为真实值,绿色,黄色和红色分别为 deepar,mqrnn 和 mqcnn 的预测值。蓝色为集成后的预测值。集成后的预测值比单个模型的预测值更稳定,更接近真实值。
count 型数据使用 xgboost 集成
rate 型数据使用 FFNN 集成
根因定位
可加性 KPI (如登录量、支付成功数等)是业务中的一类重要的指标。当可加性 KPI 总指标发生异常时,我们希望使用根因定位算法快速定位导致总指标出现异常的根源(例如:南京地区的 iOS 端的家电品类的支付成功数异常导致了总的支付成功数发生异常)。
此种方式存在两种不同的挑战:首先,不同维度值组合之间不是相互独立的,根因的异常通常会传播到其他维度值组合,导致不同维度值组合异常的纠缠,真正的根因难于甄别。其次,要对异常根因进行定位,须对所有维度值组合构成的巨大空间进行搜索。以登录线为例,数据包含 4 个维度,总的最细粒度维度值组合数量在百万量级,而搜索空间更是百万量级的指数级别(>2^1000000)。
针对上述难点,我们探索并利用 Hotspot[3]算法作为解决方案。该算法的核心思想包括以下三方面:
ripple effect:异常传播模型,用于解决维度值组合之间异常的互相纠缠问题。
potential score:用于评估某维度值组合作为根因的置信程度。
蒙特卡洛树搜索(MCTS):用于解决在巨大空间中的搜索问题。
处理流程
运维知识图谱
背景
在日常运维监控中,线上会产生大量的告警信息,这些告警信息有很多是重复和无效的,不仅对运维人员产生了较大的困扰,也极大的浪费了资源。通过引用软硬件知识图谱,对告警信息进行有效收敛,并利用告警知识图谱进行根因定位,降低运维成本,迅速发现问题、定位问题和解决问题。告警知识图谱原型如下:
构建流程
1. 样本构建
告警数据分类:将告警数据分为物理机、虚拟机和软件 3 大类,并根据告警内容细分为对应的子类。
告警数据关联汇聚:利用软硬件知识图谱将有关联的告警汇聚为一组。
时间片分割:根据不同时间粒度分割得到样本。
2. 因果发现
因果发现算法学习因果图:利用 CausalDiscoveryToolbox 中的 CGNN、PC、GES、LiNGAM 等算法对不同时间粒度的样本构建因果图。
因果图分析及告警知识图谱构建:对算法构建的因果图进行分析整合,构建告警知识图谱。
3. 因果推理
告警知识图谱边权重计算:利用告警时序数据及同济论文中的方法计算告警知识图谱中边的权重。
因果推理:根据带权重的告警知识图谱及告警数据利用路径搜索方式得当疑似根因路径排序,给出可能的根因路径。
大规模海量日志分析的 818 保障
目前日志分析平台支撑近 2500+系统的应用日志、每天 50TB+/1300 亿条数据,24 小时不间断索引服务,峰值 400W/s 写入能力,秒级检索能力。支持的日志类型包括:CDN 全量和异常日志的监控、核心链路(购物车、四级页等)Web 日志监控、应用服务器、操作系统内核等日志监控、核心数据链路日志监控等。近 1000+仪表盘覆盖完整的基于日志监控能力,保障日常和大促时段线上系统的平稳运行。在整个日志分析平台的建设过程中,我们经历 5 个阶段的不同优化,接下来我会对不同阶段的优化点和产生的问题进行详细的阐述,我们是如何一步步支撑起大规模海量日志数据的。
海量日志实时搜索
日志实时分析仪表盘
阶段一
最初,日志分析平台的 es 集群中所有节点都使用虚拟机,日志索引是按照天为单位进行生产,通过 Nginx 将用户的检索请求负载在数据节点。该架构的整体概览如下:
日志分析平台架构 1.0
但是,随着日志接入量的不断上升,这样的配置在生产环境运行以后逐渐出现了部分索引节点负载非常高,索引速度非常慢,经常出现 Kafka 堵塞情况,查询响应非常慢的状况。为此我们对这样的情况进行了原因分析,部分虚拟机在同一个物理机上,数据节点间的资源竞争非常激烈,数据节点同时承担索引和检索,负荷重,索引时有非必须的字段被索引(比如_all)和按天生成的索引太大。
阶段二
针对这样的情况,我们开始考虑对整个日志分析平台的架构进行优化:引入 client 节点,将检索的请求从数据节点转移到 client 节点,同时 client 节点通过 river 从 kafka 中拉数据将数据导入 ES。移除在同一物理机上的虚拟机,并增加了一批物理机。关闭_all 字段并且索引按照小时生成。根据日志类型划分不同的索引文件。此时,优化后的架构如下所示:
日志分析平台架构 2.0
虽然经过了优化,但是线上环境运行的过程中还是会出现一些状况:例如,非大促期间,索引和检索速度基本能达到秒级,但是大促期间,出现日志量膨胀以及访问人数过多时,索引和检索速度很慢。随着集群规模的增加,运维的工作量也急剧增加。我们对此也进行了相应的复盘和总结,主要多种类型的日志(例如偏统计分析的 web 日志,偏检索的应用日志)混在一个大集群中,不同的日志间相互影响,缺少必要的降级功能。
阶段三
在经历了两次架构优化以后,我们考虑根据日志类型,将大集群拆分成不同的小集群将 data 节点替换成物理机,提供按照系统、文件路径、等级等应对大促期间的日志洪峰系统进行降级的功能。架构也随之变化如下所示:
日志分析平台架构 3.0
此次优化我们能够非大促期间,索引和检索速度达到秒级。大促期间,通过必要的降级,能够保证重要系统的索引和检索速度达到秒级。但是用户提出了更高的要求,希望保留 7 天以前以及大促期间数据。我们也发现,随着业务量的快速增长,简单的按照分析类型进行集群拆分已不能满足要求,并且增加机器资源容量并不是线性增加。集群容量以及性能也存在严重问题。
阶段四
我们继续对 es 集群进行拆分,支持按照业务划分以及数据类型划分集群,使用不同的硬件划分 Hot/Cold 节点,业务低谷将历史数据迁移到 Cold 节点,针对 Exception 等重点关注且长期保留分析的数据单独存储。
日志分析平台架构 4.0
阶段五
随着集群规模数量越来越多,由于使用 tribe 对集群元数据进行管理,当连接的集群规模越来越大以后,元数据同步会发生延迟。CCS 采用直连方式去解决这个问题,从而提升数据查询的时效性。此外,River 插件的数据处理能力较低并且在新版中已经丢弃,因此通过使用 flink 构建分布可以故障转移的日志处理集群。
改进后的架构如下图所示:
日志分析平台架构 5.0
愿景
未来,我们将会在监控运维体系的建设中融入越来越多的 AI 元素,实现真正意义上的无人值守监控运维生态体系,提升运维效率,降低运维成本。
参考文献
[1] Flunkert, V., Salinas, D., Gasthaus, J., and Januschowski, T. (2017). Deepar: Probabilistic forecasting with autoregressive recurrent networks. International Journal of Forecasting, arXiv:1704.04110.
[2] Wen, R., Torkkola, K., and Narayanaswamy, B. (2017). A multi-horizon quantile recurrent forecaster. NIPS Workshop on Time Series, arXiv:1711.11053.
[3] Y. Sun, Y. Zhao, Y. Su, D. Liu, X. Nie, Y. Meng, S. Cheng, D. Pei, S. Zhang, X. Qu et al., “Hotspot: Anomaly localization for additive kpis with multi-dimensional attributes,” IEEE Access, vol. 6, pp. 10 909–10 923, 2018.
作者介绍:
汤泳,苏宁科技集团云计算研发中心总监。从业 15 年+,一直着力于海量数据分析、基于深度学习的时间序列分析与预测、自然语言处理和图神经网络的研究。在应用实践中,通过基于 AI 的方式不断完善运维监控体系的建设,对日常和大促提供稳定性保障。
赵健,苏宁科技集团云计算研发中心首席架构师。从业 10 年+,一直从事相关的微服务架构体系、大数据存储和实时计算的研究。主导监控运维体系的平台架构和建设规划,为业务支撑提供高可用的监控保障。
施云涛,苏宁科技集团云计算研发中心 AIOps 智能运维首席算法专家。从业 10 年+,主要研究方向为:运维场景中大规模时间序列分析、预测,指标、告警等时序数据因果发现及推断,运维知识图谱构建及应用,深度学习模型的工业化落地。
评论