排行
数据库百科
核心案例
行业报告
月度解读
大事记
产业图谱
中国数据库
向量数据库
时序数据库
实时数据库
搜索引擎
空间数据库
图数据库
数据仓库
大调查
2021年报告
2022年报告
年度数据库
2020年openGauss
2021年TiDB
2022年PolarDB
2023年OceanBase
首页
资讯
活动
大会
学习
课程中心
推荐优质内容、热门课程
学习路径
预设学习计划、达成学习目标
知识图谱
综合了解技术体系知识点
课程库
快速筛选、搜索相关课程
视频学习
专业视频分享技术知识
电子文档
快速搜索阅览技术文档
文档
问答
服务
智能助手小墨
关于数据库相关的问题,您都可以问我
数据库巡检平台
脚本采集百余项,在线智能分析总结
SQLRUN
在线数据库即时SQL运行平台
数据库实训平台
实操环境、开箱即用、一键连接
数据库管理服务
汇聚顶级数据库专家,具备多数据库运维能力
数据库百科
核心案例
行业报告
月度解读
大事记
产业图谱
我的订单
登录后可立即获得以下权益
免费培训课程
收藏优质文章
疑难问题解答
下载专业文档
签到免费抽奖
提升成长等级
立即登录
登录
注册
登录
注册
首页
资讯
活动
大会
课程
文档
排行
问答
我的订单
首页
专家团队
智能助手
在线工具
SQLRUN
在线数据库即时SQL运行平台
数据库在线实训平台
实操环境、开箱即用、一键连接
AWR分析
上传AWR报告,查看分析结果
SQL格式化
快速格式化绝大多数SQL语句
SQL审核
审核编写规范,提升执行效率
PLSQL解密
解密超4000字符的PL/SQL语句
OraC函数
查询Oracle C 函数的详细描述
智能助手小墨
关于数据库相关的问题,您都可以问我
精选案例
新闻资讯
云市场
登录后可立即获得以下权益
免费培训课程
收藏优质文章
疑难问题解答
下载专业文档
签到免费抽奖
提升成长等级
立即登录
登录
注册
登录
注册
首页
专家团队
智能助手
精选案例
新闻资讯
云市场
微信扫码
复制链接
新浪微博
分享数说
采集到收藏夹
分享到数说
举报
首页
/
异常衍生路径在智能化运维中的应用
异常衍生路径在智能化运维中的应用
白鳝的洞穴
2021-07-02
436
目前的智能化运维主要依靠算法来发现运行数据中的异常,不过目前此类智能化运维的方法也遇到了一些瓶颈。最主要的问题是当我们发现了大量的异常之后很难确定异常可能带来的后果甚至确认该异常的准确性。算法用于异常预警的实用效果就更难说了,因为导致严重故障的异常在企业中也是十分少见的,而普通异常并不会对企业信息系统造成特别严重的影响,想要确认异常预警的效果就更难了。
这中间最主要的原因有几个方面,一方面是数据的问题。因为目前我们对信息系统内在理解的不足,以及以前信息系统监控建设中存在的基础薄弱问题,大量的可以有效的用于故障预测分析的指标数据并未采集或者并未被正确对的采集。因此我们手头有的指标数据不足以实现真正的故障预警。我们实用不全面不准确的数据,那么再好的算法表现出来的效果也肯定是不好的。虽然我们可能在某些局部领域获得了一定的效果,但是这种效果并不具备全面推广的基础。
另外一个重要的原因是以算法为核心的数据分析方法仅仅能够发现一些数据不正常的时间序列,并不足以通过这个异常时间序列来定位故障。哪怕是一个专家针对这种指标时间序列的异常,也需要花上点时间来想一想,才能有所发现。仅仅依靠团队中没有真正运维专家的算法工程师就更难完成这一项工作了。
实际上智能化运维这些年在算法上的突破是有目共睹的,各种异常检测、异常分析算法为海量运维数据处理提供了一个十分好的工具。在以往,数据库专家面对700多个关键指标也是无能为力的,只能根据自己的经验选择40来个核心指标去分析。在智能化算法的帮助下,数据库专家可以更快、更全面的了解一个数据库的运行状态,实现快速故障定位。在我们的多个实践案例中可以证实,数据库专家在智能化算法帮助下,故障溯源定位的时间可以缩短90%以上,故障溯源成功率也至少提高50%,这些都是智能化算法在运维领域获得的巨大成就。
依靠运维专家辅助智能化算法的方法是目前阶段智能化运维领域已经获得成功的一种方式,不过这种方式依然不够彻底,高水平的数据库专家依然不是随处可得的资源。我们需要突破这最后一公里的屏障,真正实现故障预警和故障分析的自动化。
异常衍生路径是一种可以突破这最后一公里的技术。实际上目前我们的异常检测算法是根据一个时序中的各种指标的波动特点来寻找系统异常的。其最主要的原理是我们的信息系统在绝大多数情况下是正常的,只有少量情况是异常的。只要大致确定异常的比例,我们就很容易把这些异常点与正常点区分出来。通过复合指标的异常交叉验证,就可以找到较为精确的异常点。不过最后一公里就是真正确认这个异常,并且给这个异常点一个明确的故障定义,也就是定义这个故障的具体分类。
早期我们都是想构建一种故障模型,当某些条件存在时,就说明某种故障是存在的。因此在异常点被发现出来后,和相对静态的故障模型去做拟合,就可以实现故障的自动化分类了。不过这种静态故障模型很难构建,构建的太笼统了,误报又比较多,如果太精细了,又极难拟合命中。这些都与算法团队的运维知识积累有关,如果缺乏专家的较为精准的抽象,那么这种情况就极容易出现了。而另外一方面,专家在抽象故障模型的时候也缺乏标准,模型的质量也十分不稳定。
在实践过程中,我们发现通过异常衍生路径的角度去做梳理,往往很容易抓住故障抽象的要点,完成的模型质量也比较高。比如有以下几个指标:sql并发执行数量、活跃会话数、IO延时、CPU使用率。如果下面的情况出现,那么说明IO问题导致了数据库的一系列的问题,IO问题是此次故障的根因。
如下图,是因为某条SQL的执行效率出现了问题,引起了并发IO量变大,后端存储的IO能力出现了不足,从而导致IO延时增加,让活跃会话数也大幅增加,最终导致了CPU资源不足,从而让除了这条SQL相关的其他数据库应用也受到了严重的影响。这个问题的根因是某条SQL出了问题,或者某个应用出了问题,引发了存储IO能力不足,从而导致了问题。
下面的一个异常衍生路径似乎和上面这个类似,不过实际上差异很大。同样也是某条SQL并发执行量增加,但是首先引起的是活跃会话数暴增,从而导致了CPU资源不足。引起大量的WIO,随后才引起了IO延时增加,引起了全面的数据库性能问题。
这个异常衍生路径上,可能后端存储的IO并未达到瓶颈,IO延时增加的原因是CPU资源不足了。
从上面的这个小例子我们似乎看到了一丝智能化运维突破最后一公里的曙光,这种实践确实是可操作的,也是能够很快达到预期的效果的。不过这种方法依然存在巨大的工作量。这种异常衍生路径的梳理在早期依然需要专家的介入,并且需要有大量的运维数据积累,才能形成足以覆盖运维中90%以上问题的范围。单单依靠某一个团队或者某一个企业独立工作,其难度依然很大。建立某种开源生态或者联盟是加快这一工作的十分有效的方法。不过在此类数据作为企业核心资产的前提下,这种广泛的合作联盟的建立也困难重重。我们也乐见其成,如果真的有一天能够形成这一的联盟,我们也愿意奉献出我们这些年积累的数据。
数据库
文章转载自
白鳝的洞穴
,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。
评论
领墨值
有奖问卷
意见反馈
客服小墨