前言
在2015年构建多维监控平台时用kmeans做了异常点多维根因分析的尝试，后因种种原因而搁置了深入研究。虽中止了两年，但一直未忘当初的梦想。随着掀起AI浪潮，平台和技术也已成熟，监控团队历经两个月的重新调研和预研后取得突破，另辟蹊径地找到异常点的多维根因分析方法，我们称为MDRCA(Multi-Dimensional Root Cause Analysis)算法。
这篇文章为持续两年多的梦画上一个句号，它是监控团队第一代成果总结：介绍监控多维数据特点、基于kmeans多维根因分析方法、第一代MDRCA算法和AI在监控领域应用经验。笔者不敢贪功，仅将成果描述出来，如有偏差不全之处还望与读者多交流修正。
监控多维数据特点
监控的核心是对监控对象的指标采集、处理、检测和分析。传统监控的对象是一个单一的实体，例如服务器、路由器、交换机等。这些单一对象通过指标反映运行状态，例如服务器的状态指标有CPU使用率、内存使用大小、磁盘IO和网卡流量等。
传统监控系统通过定时任务采集这些监控对象的指标数据，经过校正后存储起来用于展示和异常检测。异常检测通过判断指标是否偏离设置的阈值来标识异常事件。
在传统监控之后，将监控对象扩展为一个虚拟的业务功能或业务模块，这时的对象仍是单一的，可用一个唯一ID表达。对象的指标也相应的转变为反映业务功能状态的指标，例如接口调用次数、http返回200次数、http返回500次数等。
这些指标数据通常需要在应用程序埋点上报。数据处理、存储和异常检测与传统监控一致。
随着业务扩展，业务模块间的关系愈加复杂。通过单一对象的指标反映的状态已不能满足业务监控需求。业务异常往往体现在多个对象的指标异常，用户收到告警后需要在大量指标数据中剥丝抽茧般地分析异常原因。
这个状况伴生了运维痛点：一是告警量大；二是分析耗时长。
解决这一问题的关键是建立对象和指标的关联模型。通过相关性收敛对象和指标，减少告警量。并通过关联模型中的调用关系模型和层次关系模型快速找到问题根因。对传统监控中的对象翻译为多维度属性后对指标数据进行处理、存储和异常检测，形成多维监控。对象的维度属性将对象分类，构建了对象的关联模型。
这样对单一对象的异常检测可提炼为对某一维度属性的异常检测，从而减少检测对象。在发生异常后根据维度下钻分析，有规则地提供分析路径，避免盲目分析，减少分析耗时。
用A、B和C这三个业务模块来说明上面介绍的多维监控形成过程：
这三个模块的调用关系为A调用B，B调用C。C根据机房划分为C1和C2两个子模块。A模块下有2台机器(10.0.1.1和10.0.1.2)，B下有3台机器(10.0.2.1、10.0.2.2和10.0.2.3)，C1下有1台机器(10.0.3.11)，C2下有2台机器(10.0.3.21和10.0.3.22)。
假设C模块下的机器负载已饱和，也就是说如果其中有一台机器异常，则提供有损服务，影响B和A的成功率。如果C2模块下的10.0.3.21机器异常，则会触发10.0.3.21机器告警及A和B下的5台机器告警，总共有6个对象产生告警。
在实际运营中，往往有多个指标反映一个功能状态，进一步增加告警量。
为解决例子描述的告警量大和分析耗时痛点，将监控对象的机器翻译成业务模块，从而形成一个业务模块和机器的多维度数据。异常检测也由机器维度更改为业务模块维度，减少检测对象的数量。在分析异常时，沿着业务模块到机器的层级关系可查找出异常点。
还有一种多维数据的场景是面向APP应用。APP的请求自身带有版本、机型、运营商和地域这些维度信息。发现指标异常后需要判断是哪个维度特性造成的异常或异常影响的维度范围。
监控多维数据由三部分组成：
时间维度，监控系统时间粒度通常取1分钟粒度；
业务特性维度，后端服务的维度通常为业务模块，APP监控的维度通常为版本、机型、运营商和地域；
指标，如成功率，耗时和延时分段统计等。
下表是一个SNG移动监控的多维数据样例：
基于Kmeans分类的多维根因分析方法
在建设多维监控平台初期，为解决人工逐个观察各维度的异常数据带来的效率问题，使用kmeans对成功率指标分类。推荐出分类后的异常维度后再做二次分析。
下图是2014年12月手Q接入层SSO模块的成功率分钟曲线。当天中午13：00附近接入层成功率由接近99.9%下降为99.5%。
发生异常后，通过人工分析的步骤为分别查看某一维度的成功率，找出成功率低并且总量大的维度条件。选定最可疑的维度条件再重复刚刚介绍的分析过程。直到遍历完所有维度，找出成功率下降的维度组合。
例如：模块维度有A、B和C三个模块，A模块下有命令字(a1，a2和a3)，B模块下有命令字(b1，b2)，C模块下有命令字(c1，c2和c3)。在异常点的指标统计如下表：
按模块观察，模块A的成功率为99.75%，总数为300；模块B的成功率为95.83%，总数为150；模块C的成功率为99.4%，总数为300。
经过比较，模块B成功率显著低于模块A和模块C，并且接近95%。模块B成为可以维度条件。
接着观察模块B条件下的命令字，其中命令字b1的成功率显著低于异常点平均成功率95%。
分析完成后确定模块B的命令字b1造成成功率下降。
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/tech/cloud/171241.html