生活_傻大方

  1. 首页 > 人文 > >

当数据库遇上"自动驾驶"，阿里云 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 。



上一篇：开发效率不高？强烈推荐这十款精选IDEA插件

下一篇：氢燃料电池是新能源大趋势 那么氢从哪来？贵不贵？