正文
假设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成为可以维度条件。
