当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破( 四 )


3) 异常序列聚类模块(TOPIC):
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
通过异常指标的相似度聚类完成iSQ1和iSQ2的相似度匹配 , 如果两个iSQ的相似度匹配很高 , 认定为一类异常序列相似度算法Sij表示iSQ i与iSQ j的相似度 ,T表示指标类别 , |Kit,Kjt| 表示每个指标之间的相似度 ,
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
关联匹配的算法如下 , 通过KDTree的加速 , 结合层次聚类完成多指标异常序列的相似度匹配 , 相似度的阈值参数调整可以基于海量数据分类获得 。
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
聚类方法我们同时也进行了多个方法做了对比 , Topic表现较好 。 同时也对异常抽取模块 , 和关联分析模块的作用同时做了相应的对比:
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
4) 贝叶斯案例模型模块 BCM illustration
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
BCM作为基于实例的方法主要是通过一些代表性的样本来解释聚类/分类结果的方法 。 通过观察代表性的样本 , 我们可以直观得获得其对应族类的样本宏观特征 。 通过Topic对异常序列的聚类产出的结果还需要增加序列的可解释性 , 通过BCM进行相关数据的整合 , 进而将异常序列(Patterns)进行整合 。
下图是DBA标注时候的案例 , 通过标注历史的案例 , 来对现有的iSQ进行判定:
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
例如 mysql.cpu_usage +,mysql.select_ps+, mysql.qps+ 异常 , BCM可以通过相似指标序列产出 , CPUIntensiveWorkload, 这样的聚类结果 , 当异常序列不在我们已知聚类序列里面时 , 通过DBA的标注 , 可以标注出更多的异常序列 , 我们的后端案例库会越来越丰富 , 聚类效果会越来越明显 , 总分类如下图
我们最终实现了从根因分类到Solution的初步映射 , DAS的决策中心会根据不同根因和其现象的patterns , 来分发自治Action消息到各个自治业务模块 , 摆脱了单纯依靠规则驱动的方式 , 通过数据在各业务场景的内循环 , 我们的模型也同时在不断更新和迭代 , 当新的根因和场景出现时 , 我们的分类会越来越细 , 同时可以适应多种业务场景和自治场景的根因定位 。
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
当数据库遇上"自动驾驶",阿里云 DAS 在自治诊断的突破文章插图
AutonomousDiagnose 的实践
我们HA的SQL是一个比较典型的场景 , 我们通常使用探活SQL去探测数据库实例的心跳去保证数据库的可用性 。
但是当这个探活SQL变为iSQ的时候 , 数据库通常会出现严重潜在的问题 。 对于数据库无征兆"突然挂掉"的问题 , 我们很难通过数据来推算出时间 , HA通常通过探活SQL来解决"突然挂掉"的问题 , 但是在review阿里集团和阿里云大量的故障case后 , 我们往往很难取判断数据库"半死不活"的场景 , 因为探活RT的连接还是可用的 , 但是SQL的RT会变慢 , 而传统基于规则的监控时很难能检测出这一类问题的 , 我们这两年线上很多故障都是这种现象 , 而一直没有很好的解决办法 。 通过探活SQL变为iSQ的检测 , 我们可以站在用户视角第一时间发现SQL请求变慢的现象 , 一个"监控检测"的问题就转化成了一个"预测性维护"的问题, 提前发现潜在问题并定位根因发起自治action 。


推荐阅读