TiDB 可观测性方案落地探索 | “我们这么菜评委不会生气吧”团队访谈

Posted 2022-03-15 TiDB_PingCAP

在 TiDB Hackathon 2021 赛事中，没有错过任何一届赛事的元老级选手王鹏翰再次得奖，也是继滑滑蛋之后，又一支男女朋友并肩参赛的队伍。

王鹏翰目前工作于思科旗下做应用性能管理的公司 AppDynamics，主要从事日志搜索引擎的研发和可观测性相关的一些工作。陈思雨是 PingCAP Chaos Mesh 团队的研发。

这次的参赛项目 Collie Diagnosing Platform，是一个集故障场景信息收集、UI 在线观察分析、机器学习辅助诊断于一身的故障诊断分析解决平台。结合了两人在工作中的实际场景，探索了未来 3-5 年 DBA 和运维人员的工作方式，评委们给予了非常高的评价和期待，拿下了本届 Hackathon 的三等奖。

项目意义重大，让 DBA 在分析问题时，面对那么多 Metrics，不再那么头大。

——多点 Dmall 数据库团队负责人冯光普点评

数据库自治是领域的重要方向，参赛团队在理论和工程实践方面都做的比较好，后续可以进一步对标阿里云的 DAS 产品进行改进完善，将弥补这一领域项目在开源方面的空白。

——美团数据库研发中心负责人李凯点评

关于团队
Q：这个队名的由来有什么故事？

陈思雨： 队名来自于 Dota 的一个语音包，在游戏里如果队友做什么比较蠢的操作的时候，播放下这条语音就达到效果了。

可以通过这条视频体会一下： https://www.bilibili.com/video/BV1N34y1m7wa

Q：两位都是 Hackathon 的老选手了，Hackathon 对你们的吸引力是什么呢？

王鹏翰： 对我来说 Hackathon 就是进行一个 deadline 的设置，逼着你在很短时间内学大量的东西。本来我很早就想去学习一下如何用机器学习做一些根因性分析相关的东西。但是已经想了一年，实际上只看了一点点。在 Hackathon 中，就可以在很短的时间内了解它并且把它使用起来。有一个 deadline 就会逼迫你快速去学习，这个时候学习效率非常高，睡觉的时候满脑子都在想着这个地方还能怎么优化一下，那个地方还怎么搞。当然，顺便还能拿到一点奖金。

陈思雨： 跟他差不多。另外，在 Hackathon 里还能看到很多不一样的 idea。

项目灵感
Q：你们最初为什么会想到要做这样一个项目的？能分享下你们的灵感是什么吗？

王鹏翰： 我们前两年参赛基本上都是在做 FDW，就是给 TiDB 接一个通用的外部数据源，今年的一等奖项目从某种意义上来说也是外部数据源的一种。感觉已经做得有点心神憔悴了，那些 Hard Code 的功能对于我们这种老年人来说，无论是脑力还是体力都已经跟不上了，今年就只能在搞花活的方向去另辟蹊径。

我找项目灵感的一个核心点是去发掘身边真实遇到的一些情况，试图抽取出一个通用性的问题，然后去想如何通过工具或者方法论把它高效地解决掉。包括去年的 idea 如何写出一份优雅的文档，今年的 idea 如何快速地发现故障和诊断故障，都跟工作是息息相关的。

我现在的工作是在可观测性领域，这个领域目前跟机器学习相结合的东西大多都还在论文阶段，但在实际环境中如何把它更好地落地，还是比较少有人去尝试的，刚好 TiDB 已经把整个基础做得非常好了，就想借 Hackathon 的机会来做一些尝试。

Q：在这次比赛过程中，你们的队伍成员之间是如何分工的？

王鹏翰： 思雨负责如何用 TiDB 去模拟故障的发生，刚好也用了他们团队的产品 Chaos Mesh。然后我使用一些工具来代替人脑，观察这个时间段是否发生了问题，用机器学习的方法代替人做一些简单的判断。就等于说运维人员有一个很大的屏幕，上面有几十个图，每个图里都有很多的折线。一般情况下，如果一个系统在平稳运行的话，这条线基本是平的，但出现故障的时候，会有很大的波动。

现在都是 DBA 用人眼去观察，故障的判断也是基于人的经验和思考模式。但现在 TiDB 中像这样的指标就已经有几千个了，未来还会有更多。这就意味着靠人去观察这些东西会变得越来越复杂，越来越慢。我们可以用机器去帮你快速地筛选出来，比如 1000 张图中有 10 张图有这种故障，然后你再去观察这 10 张图就可以，帮你节省了大量的时间。

在理想的环境下，准确率能达到 70-80%。但如果在现实环境中，你可能认为有些并不是故障，所以这个指标会有一些波动，噪声会很大。

技术困难&应对
Q：在比赛过程中你们遇到过什么比较大的技术困难？

王鹏翰： 主要是数据集质量问题。目前在 AI 领域，算法可能不是最关键的，最关键的是数据集。如果你的数据集够好，通过相应的算法都能得到一个很好的答案。但如果你的数据集比较糟糕，那你得出来的答案永远是错误的。所以我们花了很多时间在数据集模拟这一块。

另一块就是在思考如果换我来运维系统，从 DBA 的角度来看问题的时候，我该如何合理设计用更高效合理的方式来做这个事情。其实不管是 TiDB 也好，还是一套系统也好，都有一套共用的方法论，可以通过观察资源，比如 CPU 资源或内存资源，或者观察事务（一个http请求，一个数据库查询请求）。从而知道系统是否按照预期在运行。如果没有按照预期运行的时候，我们的应用能给一个告警，还能告诉你是什么原因导致系统没有按预期运行。

这就是所谓的根因分析（Root Cause Analysis），我们希望通过机器学习，告诉你发生故障的原因是 CPU 不够，还是机器上有另外的任务抢了 CPU 资源，那你就应该去加更多的 CPU 资源。

陈思雨： 其实其这个问题不应该仅仅是 DBA 或者运维关心的，因为他们（王鹏翰所在的 APPDynamic）是全员 Oncall 的，所以他会思考遇到一个 Oncall 的问题应该怎么去解决，应该怎么去优化这个 Oncall 的流程。我们这次做的项目也是在优化这个 Oncall 的整体流程。

DBA 可能会更专业一点，我们这次做的产品是面向那些非 DBA 人员，因为 DBA 看 Grafana 这种比较专业的指标就会有很明确的一个判断。但是如果是刚上手的人，比如说刚开始学习 TiDB，也可以通过我们的产品有个初步的方向判断，这个故障原因是一个网络延迟还是怎样。

王鹏翰： 遇到的另一个问题就是现有的机器学习也好，深度学习也好，离所谓的 AIOps 还有非常远的路要走，而且有很大的难度。为了这次的项目能有一个成品出来，主要依赖了两篇论文，一篇是 SIGMOD 2016 的《DBSherlock: A Performance Diagnostic Tool for Transactional Databases》，另外一篇是 VLDB 2020 的《Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases》。

这 2 篇论文做得非常好的一点就是把场景局限起来了，针对一个小的领域、小的场景能做到高度的准确性，比如一个运维可能 10% 的工作是在处理这类问题，那这个项目能自动化地解决这 10% 的工作量。然后像拼积木一样，今天把这个问题的积木拼装好，下次把另外一个问题拼装好，慢慢就把整个全自动化的事情给拼接出来了。

未完成的遗憾 & 期待
Q：这次 Hackathon 的时间有限，你们在比赛过程中有什么遗憾？

王鹏翰： 体验满意，完成个人的既定目标，在短时间快速学习了机器学习，并做了个小产品。aiops 可以在一些特定的领域降低人的工作负载，但离最终广泛的替代运维还有非常远的路。

陈思雨： 8 分钟的演示时间太短了，我们一直在缩减 PPT，调整我们要突出哪些重点，还要保证在这么短的时间内让这么多位评委老师都 get 到。

Q：你们的项目这次获得了三等奖，对这个项目未来有什么展望与期待？

王鹏翰： 首先，这个项目的实现方法还非常雏形，有很多的细节还需要跟大家探讨和交流才能摸索出来。而且我们也没有希望把这个项目做成一个产品，更多的是方向上的探索，探索未来 3-5 年运维或 DBA 的工作方式。

随着技术的突飞猛进，运维的难度也越来越大。运维的管理对象从原来的单台机器变成了云和 Kubernetes，节点越来越多，涌现出来的信息也越来越多。从开发的角度来说，会把更多的信息暴露出来，统一地进行管理和追踪。但如何更好地利用这些信息？这个领域在国内还是鲜有人去思考的，也就是所谓的可观测性（Observability）。

国外很多公司，包括我们公司（AppDynamic）都是这个领域的主要参与者，在非常活跃地往这个方向进行一些探索。PingCAP 已经算是做得很不错的了，把整个数据库的可观测性做得很好。希望国内有更多的公司和个人能去思考一下，如何运用现有的工具，让你的系统有更好的可观测性，从而降低运维压力和成本。