智能诊断 vs 人工诊断 —— 从五分钟定位并排除一次数据库连接中断问题说起...

云和恩墨

于 2022-06-21 16:30:39 发布

阅读量659

点赞数 1

文章标签：数据库运维大数据人工智能 java

本文链接：https://blog.csdn.net/weixin_54551388/article/details/125401714

版权

智能运维的一个重要任务是故障智能诊断，用智能化的手段辅助和代替运维人员的责任。然而故障诊断能做好并不容易，因为IT系统太复杂了，数据库系统本身就有数百个相互关联的参数，牵一发而动全身。加上数据库运行的复杂环境，包括不同类型不同厂商的操作系统、服务器、网络、存储、虚拟机、集群、容器等等，复杂度指数级提升。在人工诊断的模式中，专家首先会基于自己的经验，穷举自己脑子里与故障情况相关的诊断路径，然后逐步缩小诊断范围，最终定位问题。当已知路径无法定位问题的时候，专家诊断就会陷入瓶颈，此时专家需要通过知识库查找或向外求助来扩大诊断范围，并逐一排查，最终定位问题。这就形成了传统的人工运维模式。

智能诊断和人工诊断的路径差不多，从已知问题的起点开始搜索诊断路径，但智能诊断的诊断路径来源于专家知识、案例积累、历史数据等多种渠道，因此智能诊断初始化的诊断路径数量要远远多于人工诊断。而且，智能诊断利用关联性分析，对诊断路径可以快速收敛，叠加机器的算力，可以相对人工诊断更快速更准确地发现和定位问题。与此同时，新的诊断过程和结果可以回馈给系统积累成新的经验，为以后的诊断提供参考。智能诊断形成平台化的新模式：

我们来看一个案例：最近某企业的 IT 系统上遇到的一个突发问题，已连续稳定运行361天的多个业务系统突然出现报警，检查发现“数据库无法连接” 。

DBA紧急登录 zCloud 系统，切换到健康评分看板查看问题，发现数据库健康评分跌落到0分，显示排名第一的问题是数据库无法连接（如下图）。

迅速下钻，点击该问题查看详情，发现诊断分析给出的原因是“会话耗尽”，并明确诊断到 ORA-12520 报错。这个依据很充分，DBA确认。

但是，会话为什么会突然耗尽呢？DBA带着这个问题继续查看，发现排名第二的也是一个严重问题（如下图）——“等待/堵塞会话数过多或者过长”，而且监控数据显示当时活动会话数高达885，已经占到设置的数据库最大连接数上限的85%以上（此案例的上限设置为1000）。

同时，智能诊断已经给出解决办法，最优的是“禁用密码错误延时登录功能”，点击查看解决办法详情（如下图）。

看到这里，DBA已经非常明确，引起问题的原因是未禁用密码错误延时登录功能导致。不用再往下分析了，直接后台登录 SQLPLUS 使用这个方案，紧急设置 28401 事件，果然很快的解决问题，业务恢复正常！

整个问题发现和定位的过程很快，DBA只用了不到5分钟就定位并排除了这次数据库连接中断故障。如果依赖传统人工分析，即使是很有经验的DBA，也无法在这么短的时间内完成。针对当时大量会话被锁定问题，zCloud 首先识别出大量 SQL 语句被 librarycachelock 堵塞，且 librarycachelock 的锁类型是47-> accountstatus，最终根因明确地命中“Oracle 数据库密码错误延时登录的功能”（如下图）。

继续观察诊断树可以发现，zCloud 在找到 SQL 语句被 librarycachelock 堵塞时，从已知问题的起点遍历了许多诊断路径（如下图），排查了 CPU、网络、UserIO、各种锁等等，诊断路径的覆盖完整度很高。这些诊断路径来源于基于专家经验的诊断模型。在根因分析的过程中，每一个节点的判断都不是独立的，上下级均有逻辑关系。以检查点异常为线索，每一个检查节点都有独立的数据采集、加工、以及判定问题的规则，只有在上一级判断为存在问题的状态时，才会继续向下一级，所以在扫描每一级检查节点的同时也在对诊断路径做收敛。

例如这个案例中第一层扫描后，发现主机可以连接，但是数据库无法连接，所以主机相关的下级路径不再继续扫描，从而避免对所有诊断路径做无谓的扩张，给系统带来不必要的负担。识别 SQL 语句被 librarycachelock 堵塞后，再层层深入，靶向性并有策略的快速收敛，最终找到无法连接的原因是 12520 错误，典型的数据库会话资源耗尽导致。事后回溯，正是由于业务使用期间调整了用户密码，但是部分业务没有重启才导致了这个问题的发生。

本案例并不复杂，但如果是人工诊断，短时间列举出这么多条诊断路径几乎不可能，排查3-5个诊断路径后也已经耗费大量精力。这在数据库无法连接、业务中断的情况下带给运维人员的压力可想而知。而智能诊断工具，恰好可以在诊断路径的发散与收敛以及算力上弥补人工的不足，切实帮助运维人员解决问题。

还有人问，在用户环境里，运维对象都具备十分强的个性化，智能诊断通用诊断模型是否能发挥作用？zCloud 的做法是：除预置的专家诊断路径外，智能诊断在使用过程可以同步吸收用户经验，通过自定义诊断树将个性化案例积累丰富到智能诊断中，实现智能诊断模型的不断进化，用户环境使用越久，智能诊断越能准确高效。

zCloud 数据库云管平台，身边的“数据库专家”

云和恩墨 zCloud 数据库云管平台，基于 WaaS（Wisdom as a Service，智慧即服务）理念打造知识库与智能诊断功能，将行业最佳实践和专家经验转化为平台能力，让高级“数据库专家”实时在线，有效保障数据库稳定高效运行。

WaaS 模型从数据到智慧，持续将专家经验代码化，为平台动态赋能：数据层面利用管理大数据，实现对数据库做精准画像，改变过去基于指标运维的不足；知识层面通过共建共享知识库，解决过去管理经验孤岛、样本不足的问题；智慧层面通过用户贡献个案、专家标注、机器学习三个来源生成知识点、案例、算法，实现经验代码化。

智能诊断, 精准定位问题根因

zCloud 智能诊断覆盖数据采集→问题感知→自动诊断→识别根因→故障自愈五个阶段。从数据采集开始，在不影响数据库稳定性的前提下，最大程度覆盖和优化采集指标，并通过一系列算法，过滤分级，收敛检测点，降低误报率等，破除浅层表象，同时进行事件关联，自动生成诊断关系树，层层深入，最终找到问题根因，并提出解决方案。