阿里搜索监控数据平台的AIOps实践

1 .阿里搜索监控数据平台的AIOPS实践 演讲人：施立 全球敏捷运维峰会 广州站 

2 .Agenda 1. kmonitor 概述 2. 数据平台设计 3. AIOPS探索案例 全球敏捷运维峰会 广州站 

3 .Why 全球敏捷运维峰会 广州站 

4 .监控数据平台总结 运维数据仓库 基于大数据的 • Metric • 过去，现在，未 • Event 来 基于算法的 • Log • 数据标准统一 • 发现问题 特点 • 数据种类丰富 • 诊断问题 • 面向机器，面向管控 • 优化建议 • 决策建议 基于管控的 Razor + Apack 目标 • 可重入 • 助力运维能力升级 Action+Diagnose+管控 • 算法服务框架 • 自我保护 • 助力管控能力升级 • 时序数据分析 • 从手工处理到自愈 • 反馈和自动调优 • 诊断经验沉淀 • 算法持续迭代 全球敏捷运维峰会 广州站 

5 .kmonitor overview 全球敏捷运维峰会 广州站 

6 .异构数据源采集 日志ETL : select sum(line[4]) tag(cluster, line[2][4], scene_id, line[3] where line[6] > 3 and line[7][1] != “heart beat”) Log System SDK plugins Promethus Support OpenMetric exposition format 标准，开放，共建 Service Discovery (Armory, Drogo) 全球敏捷运维峰会 广州站 

7 .时序数据库演进 精于聚合，弱于明细 精于明细，弱于聚合 No Silver Bullet 全球敏捷运维峰会 广州站 

8 .Druid的选型和优化 Druid ON Yarn Druid ON Hippo (K8S) Swift Extension SLS Extension HDFS Deep Storage OSS Deep Storage 全球敏捷运维峰会 广州站 

9 .Druid的选型和优化 _metric tagk1 tagk2 …. min max avg sum count 1. 数据精度对应不同datasource (20s, 1m, 10m, 60m) 2. Shuffle算法平衡数据热点和查询效率 3. CompositeSegment解决数据空洞，大幅解决写入查询性能 1. 200+ Tag Group, Not Too much 2. 更高效解压命中相同metric数据 3. persist耗时减少60%, merge耗时减少90% 4. 辅助结构占用内存，history lazy load 全球敏捷运维峰会 广州站 

10 .海量指标存储Gnomon（分布式Influxdb） 5000w/s points scale out query ms latency 全球敏捷运维峰会 广州站 

11 .高维指标聚合juicer 高维单指标聚合：单指标tag value的笛卡尔乘积 > 10w docker.cpu.percent 全球敏捷运维峰会 广州站 

12 .高维指标聚合juicer 高维多指标聚合：wildcard:false:blink.*.tps.rate 全球敏捷运维峰会 广州站 

13 .高维指标聚合juicer 高维指标四则运算 全球敏捷运维峰会 广州站 

14 .高维指标聚合juicer 用户无感知，0配置，TSDB容灾Backend 全球敏捷运维峰会 广州站 

15 .AIOps平台Razor 简化时序数据使用门槛，让数据更大发挥价值 OPS UDF Blink Job 规则报警 10w + rule DataPoints DownSample GroupBy Arithmetic stream 异常检测 1w + rule Event 巡检任务 定时batch TSDB 容量规划 OpenTsdb Query 统一表示 AIOPS Serverless Platform 全球敏捷运维峰会 广州站 

16 .管控平台Beacon 1. 租户自动新建和容量管理 (写入，存储，查询，报警计算) 2. 慢query治理建议 3. 多区域多集群一键部署和稳定性管控（kmon on K8s, kmonitor operator） 4. KAM巡检与自愈 Cloud Native Solution kubernetes operator kmonitor 全球敏捷运维峰会 广州站 

17 .Why AIOPS AIOPS意义：利用算法的能力进一步提升系统效率，降低运维成本 全球敏捷运维峰会 广州站 

18 .异常检测报警 规则报警的优缺点： 1. 报警模板管理时,一套参数不适合所有的应用, 误报较多 2. 没有考虑历史信息,无法解决周期性问题 3. 计算简单,易于解释 算法报警的优缺点： 1. 一套参数适配一类应用,考虑了历史信息,比较符合人的报警 直觉,减少误报 2. 目前比较适用于周期性和稀疏性较强的数据 3. 计算复杂, 不易于解释 全球敏捷运维峰会 广州站 

19 .基于分解的异常检测算法 vs. 基于预测的算法 全球敏捷运维峰会 广州站 

20 .RobustSTL Challenge：去除周期影响 周期偏移：比如在集群上系统的负载在今天13：00的值可能与昨天12：45的 值接近（即15分钟的偏移量） 全球敏捷运维峰会 广州站 

21 .异常检测报警 算法基本原理: • 对数据进行预处理(稀疏/周期性判断,稀疏处理等) • 对数据进行分解, 有周期数据分离,STL分解(Seasonal-Trend decomposition procedure based on Loess)等 • 然后选择数据分量进行统计学检验.依据检测类型选择不同的检验方法. 目前算法支持的异常检测类型: • 尖峰 & 深谷 异常(使用ESD(Extreme Studentized Deviate test)检验) • 均值变化(使用T-test检验) • 方差变化 • 长期趋势变化 全球敏捷运维峰会 广州站 

22 .异常检测 异常检测自动调优流程 全球敏捷运维峰会 广州站 

23 .尖峰&深谷异常 RobustSTL + ESD RobustSTL + ESD ESD 对原始数据进行分解,去周期性,然后对转换后的数据进行ESD检验 全球敏捷运维峰会 广州站 

24 .均值变化 基本思想是取左右两个窗口，左窗口包含过去时间的数据，右窗口包含最新的数 据，利用t-test的原理来比较2个窗口的均值是否有个很明显的变化。 通过调节窗口的宽度，可以调节检测的延时，就是变化要持续多久才会被检测到。 全球敏捷运维峰会 广州站 

25 .异常检测产品化 全球敏捷运维峰会 广州站 

26 .异常检测-现状 • 上线tisplus及tpp等头部业务5k+条核心指标， 日均调用量500w+ • 相比规则，报警量减少97%，避免了大量误 报，依据1000+（标注次数）人工标注，准 确率和召回率均>90% • 针对周期性，稀疏数据，均值变化做到了比 较好的识别和处理 全球敏捷运维峰会 广州站 

27 .通用的AutoScale 全球敏捷运维峰会 广州站 

28 .我们的AutoScale 调度，管控系统解放了我们大量的运维精力，但是容量的管理仍然是我 们在DevOps中面临最大的挑战。 全球敏捷运维峰会 广州站 

29 .弹性Quota 全球敏捷运维峰会 广州站