扫码阅读
手机扫码阅读

TiCheck 在 TiDB 的“马拉松”之旅

1290 2023-09-07

江坤

什么都懂一点点的程序员..

TiDB Hackathon 大赛

TiDB Hackathon 是 PingCAP 举办的黑客马拉松比赛。


比赛内容围绕着分布式数据库 TiDB,对 TiDB 的生态工具,内核功能等进行优化或开发。

/ 主题赛道

从2017年开始,今年已经是第四届Hackathon,主题为 “Explore the Sky”

参赛的选手可以尽情发挥自己天马行空的想法,用 TiDB 创建无限的可能!

提一下,比赛奖励是相当的丰富!心动的可以期待下一届: TiDB Hackathon 2021 | TiDB 社区。

TiCheck 抱憾落败

这一次初赛共有 60 多个队伍参加,而我们也是带着 TiCheck 加入到这激烈的竞争之中。

当初赛答辩结束,青姐宣布前 20 强的时候,我看看整整三遍名单,思索了很久..


虽然很遗憾我们的 TiCheck 项目未能在这次活动中获得一个很好的成绩, 但在整个活动的参与过程中,我们全身心投入,也是收获颇丰

第一天看完大家预选赛的答辩,已充分感受到在座各位大佬的强大,但是依旧对自己的项目充满了期待,希望 Ticheck 够脱颖而出。

直到最后结果出来的时候,我们完美的发挥了鲁迅先生笔下的 阿 Q 精神,寻找各种找借口来安慰自己。


比如说这样:评委们都是一群干开发和大老板们,他们能懂个锤子的数据库运维?能懂我们做运维的痛苦吗?

而这正是我们的 Ticheck“应运而生”的契机。

下面我们来看看

TiCheck 又是如何“应运而生”的吧..

TiCheck 的缘起

咱们的这个项目 Automated checklist, 又叫 TiCheck, 这个项目最早源自我们一个 真实运维生活场景

难以维护的数据库

大家都知道,数据库是一个非常重要的系统,尤其在一些十分注重安全和稳定的业务场景中,比如金融银行型企业的数据库。

因为注重数据库安全和稳定再加上业务数据量庞大,他们的 数据库的管理和运维就十分的复杂和难受,下面举几个列子:

# 1

运维过程中脚本需求数量庞大

且难以复用

大量的日常操作必须都进行脚本化。

一套数据库得整一两百个脚本,还得现写现审核,每当上级有个新的操作需求,就需增写一个脚本。

最主要的是数据库脚本这个东西, 很难去找到现有的进行复用,每个 DBA 都有自己的小私库。

#2

运维过程中指标监控分散

故障排查低效

TiDB 有 Grafana, Dashboard 和数据库 SQL查询三种方法获取数据库的不同信息。

比如当你的网络和权限受限的时候, 你很难说去三个地方来检查数据库是否正常,同时每次查看集群信息, 得从三个地方跳来跳去的

如果能有个统一的地方来查看这些,会不会非常舒服?

#3

日常巡检重复性高

工作量大、效率低

在数据库的运维过程中需要每天上去查看数据库是否正常,有无异常和隐患。

虽然 TiDB 很稳,系统本身也有很多的监控和告警,但是为了数据安全,作为数据库运维人员就 必须每天进行所有指标的巡查,并且输出巡检记录

这个少则十几分钟,多则几小时的操作,在平稳运行的每一天都是折磨,你恨不得今天某个指标来点小问题,让自己显得有一丝价值。

数据库日常巡检之后,还 面临着这些巡检历史记录保存与否,如何保存,多久清理一次等等诸多问题。

同时如果想要查看历史巡检的情况,只能一份一份的看,如果想要看一段时间巡检的统计和分析,还得手动操作一波,而这个又是领导们常常想要的。

#4

运维报告输出困难

且效率慢

说到领导,领导经常会关心数据库状态是否正常,用的怎么样。

这个时候, 你得写一份领导看的懂的报告,加一些易懂的图图表表

如果你把那些 Grafana 和 SQL 查询结果拿过去,我只能说很难。

最重要的是,当领导要看的时候,你得在最短的时间内拿出报告,不然有得好果子吃。

TiCheck 初具雏形

异化为机器..

在这个项目中干了许久之后,我们渐渐发现, 我们成为了一个又一个的操作机器

日复一日的脚本生成,日常巡检(点点点),文档生成。

没多少技术含量不说,每天还显得异常忙碌,到底在忙碌些什么呢?

雏形诞生

在写了无数个脚本之后,

团队中的某一位小伙伴率先发难了:

咱们现在讲的是一个什么?开源!共享!

为什么就是没有人共享一下数据库脚本,做一个脚本仓库,大家把自己的脚本上传上去,也可以从上面下载各种各样的脚本,这难道不舒服?

团队中的另外一位小伙伴觉得:

不如做一个巡检平台

最好一键巡检完,生成报告,免得每天花一堆时间做巡检写报告,跟个机器人似的。

最好是那有那种可视化的展示模式,这样方便日常监控,也方便随时进行工作汇报。

所以,为什么不两个合在一起呢?

刚好就在这次 Hackathon,我们可以开发一个 日常巡检平台

欸~,就是冲,说不定还能白嫖十万块钱。


TiCheck 修成正果

这个平台可以干什么呢?

#1

拥有远程共享脚本商店

平台上设立了远程仓库,里面存有大量通用的数据库脚本。

大家 可以寻找自己需求的数据库脚本,加入到巡检指标中,一键巡检并输出结果。

同样的,如果你有着非常好用的脚本,也 可以贡献到仓库分享给其他人使用

/ 远程的共享脚本商店

#2

统一的巡检指标输出平台

日常巡检中,你可以通过脚本可以访问 Dashboard 和 Grafana,也可以直接访问数据库通过 SQL 获取相关集群信息。

从不同的数据源会统一输出到该平台进行可视化的展示。

/ 统一的巡检指标输出平台

#3

支持一键巡检的巡检管理平台

在该平台上,你可以选择脚本和相应的指标后,进行 一键巡检,然后就可以查看巡检的报告,无需过多的操作。

通过对于历史的巡检结果,你可以在平台上进行管理,包括 下载报告,导出历史,定时清理等等

同时对于大量的历史巡检结果, 也会做一个简单的分析进行展示,供运维人员参考。

/ 巡检管理平台

#4

指定的巡检报告输出

平台支持对于历史巡检结果进行报告格式输出,输出的格式目前是 CSV,当然后期也会有Word,PDF 等其他格式的支持。

最关键的是能够瞬间及时的生成巡检报告,当老板们需要了解集群情况的时候, 再也不需要急急忙忙的四处截图,查表,画图写文档了!

暂未实现的功能

当然这个平台还可以集成很多其他的功能。

例如下面这些功能也是在我们的规划之中,但由于时间有限而没有实现:

#1

对接告警系统

每日定时自动巡检完成后,可以 对接用户的告警系统,对相应异常指标输出到告警系统之中。

或者将报告通过短信的方式发送到相关运维人员,避免人员需要每天到机房查看。

#2

预测问题

通过历史巡检数据可以对集群状态进行深度分析, 提前发掘集群可能存在问题

例如每日巡检到存储空间增长情况,来预测未来多少天会出现存储空间不足的情况。

#3

根因分析

加入根因分析功能(这个其实是我本来和另一个伙伴报名 Hackathon 比赛参加的项目,但由于他太忙了,就弃赛了)。

当发现巡检指标异常的时候,能够快速定位到集群问题的根本原因,方便运维人员的维护,避免长时间的集群排查。

Hackathon 只是一个开始,各种各样的花式 idea 在其中涌出, 打开一扇扇新的大门

TiCheck 巡检平台项目,虽然没有获得最终大奖,但是我们不希望巡检平台才刚刚开始就结束了。

因为我们相信, 会有许多人遇到和我们类似的运维问题,那么自动巡检平台就会有他存在的价值。

同样的,在日后的工作中,我们也会继续的 不断思考,不断创新,不断的踩坑实践,在拥抱开源的路途中同时也为开源的大世界提供更多的可能性。


大家对于 TiCheck 巡检平台有什么更好的想法,可以联系我们,对其进行优化,或是集成到其他平台一起使用, 欢迎交流 !

想要了解更多,点击 查看原文