从Mysql通讯丢包错误看DB AIOPS面临的挑战

白鳝的洞穴 2021-05-24

1654

AIOPS是通过数据与算法在运维中替代人的全新的运维自动化支撑手段，老白在以前也讨论过AIOPS在复杂的环境中发挥作用的问题。前阵子一个客户让我们帮助分析一下4月26号发生的一个Mysql数据库的故障，从D-SMART的报警上看，在4月26号一天里，这套Mysql数据库产生了500多个Got an error reading communicationpackets报错的信息，其中有一半以上集中在上午9点多到10点多这段时间里。而用户也是觉得这段时间里系统不正常，业务部门的投诉比较多。经过对这个告警的分析，我们发现这个告警实际上一直都存在，只是平时每天报警数量不到100个，而4月26号特别多而已。

针对这个日志报错，我们目前还没有设置专家诊断的推荐诊断路径，于是只能通过智能诊断的方式对异常数据进行分析。通过异常诊断发现，在出问题比较严重的时间段里，这个系统的数据库连接延时会出现抖动，正常正常情况连接延时不到100毫秒，而有时候连接延时会高达5秒以上，执行采集任务的时长也会出现异常，比平时慢几十倍以上。而对于网络的分析结果是，网络一切正常，无论是网卡丢包还是服务网络的拨测数据都是正常的。由于目前智能诊断针对的诊断路径都集中在连接数据库和网络上，因此我们无法通过智能诊断工具完成这次分析了。

智能手段不好使，就只能上人工了。于是我们的DBA查看了这一小时内D-SMART的所有异常报警数据。发现一个和innodb buffer相关的运维经验报警场景数量也很多。

另外从Innodb行为分析中也发现了一些异常：

这个知识点工具的最终分析结果是innodb buffer设置太小了，需要加大10倍以上，才能满足当前业务负载。于是我们建议客户调整了innodb buffer，调整后，这个报错就完全消失了。

这说明我们的分析是正确的，实际上后来我们在对4月26号的9-10点数据进行分析的时候发现，这个时间段里，活跃会话数（高峰期超过100），TOP SQL等都出现了异常。而这些都是innodb buffer设置过小引起的。

经过讨论，我们觉得，在短时间内通过纯粹的大数据分析的手段想要建立这个问题的原因是不现实的。首先目前我们的数据集中仅有这一种故障类型，并未覆盖所有的故障类型；其次是我们的系统中往往存在很多亚健康的因素，因此存在大量的干扰性的异常问题，大数据分析往往会把这些问题也和这个故障的问题产生关联，这样会导致分析出来的结果不准确；第三是客户现场的服务器算力不足，无法支撑大范围的数学计算。

事实上，针对这种跨界十分深的问题的分析，因为其涉及的领域比较多，往往是很难通过较为简单的异常检测算法来发现问题的。实际上我们以前就发现过另外一个问题，那就是活跃会话数过高的问题。这个问题几乎与我们的数据库的所有方面都有关系。2018年我们曾经对Oracle数据库的活跃会话数过高做过一个分析，发现与之相关的知识点有数百个。

基于专家与经验积累的知识图谱构建的诊断工具还是十分复杂，其使用效果并不好，有时候分析过程中发现的问题过于发散，导致问题无法收敛。于是我们只能通过一个更为复杂的专家诊断工具来替代这种基于知识图谱的诊断工具，通过专家经验去收敛诊断路径。

实际上经过专家经验收敛的诊断路径仍然十分复杂，不过比起铺天盖地的数百条诊断路径来说，已经实用多了。

事实上，这些问题是DB AIOPS中十分常见的，因此解决这些问题是考验一个DB AIOPS系统是否实用的关键，而往往这些问题又是AIOPS能力范围之外的。其中的原因除了刚才我们所说的诊断路径的复杂性与历史数据的覆盖面之外，还有一个十分重要的问题是数据的问题。可以用于诊断异常的所有指标数据我们都已经采集了吗？采集回来的数据都足够准确吗？我们的AIOPS系统建设过程中，实际上大家把更多的精力放到了算法上，而往往忽视了指标数据。可能有些朋友会有疑问了，我们做AIOPS的时候不是已经把可以拿到的数据都集中了吗？事实上，对于要完成复杂的分析，我们以前所有的运维自动化系统采集的数据都是不足够的，很多可能和这个问题有关的指标并未被采集。这种情况下，我们的AIOPS算出来的结果有可能准确吗？这个问题用屁股去想都应该不会想错吧。而另外一个事实是，做AIOPS的人也清楚这一点，但是他们往往对此无能为力。因为准确的数据采集是需要运维专家介入的，而运维专家的缺失导致了这些工作无法做到位。

回到我们刚刚讨论的问题，这个MYSQL网络丢包报错的分析已经有专家进入在分析了，而且目前也针对出问题的客户系统发现了一条有点意外的诊断路径。如果要继续扩大分析范围，还需要多一些系统产生此类报错，让我们的专家有更广的分析范围，同时在互联网上收集类似问题，进行分析也是一个无奈中的补充方法。后续对此问题的分析的一些新的进展，老白会继续和大家分享，今天就谈这么多吧。

mysql ai

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

从Mysql通讯丢包错误看DB AIOPS面临的挑战

评论