美团 MySQL 数据库巡检系统的设计与应用

说明：
做者：王琦
来源：美团技术团队
最新互联网大厂面试真题、Java程序员面试策略（面试前的准备、面试中的技巧）请访问GitHub

---

咱们生活中随处可见各类巡检系统，好比电力巡检、消防检查等，正是这些巡检工做，咱们才能在稳定的环境下进行工做、生活。巡检对于数据库或者其余 IT 系统来讲也一样相当重要，特别是在下降风险、提升服务稳定性方面起到了很是关键做用。

1、背景

为了保障数据库的稳定运行，如下核心功能组件必不可少：

其中，数据库巡检做为运维保障体系最重要的环节之一，可以帮助咱们发现数据库存在的隐患，提早治理，作到防患于未然。对于大规模集群而言，灵活健壮的自动化巡检能力，相当重要。

任何系统都会经历一个原始的阶段，最先的巡检是由中控机 + 定时巡检脚本 + 前端展现构成的。可是，随着时间的推移，老巡检方案逐渐暴露出了一些问题：

• 巡检定时任务执行依赖中控机，存在单点问题；
• 巡检结果分散在不一样的库表，没法进行统计；
• 巡检脚本没有统一开发标准，不能保证执行的成功率；
• 每一个巡检项都须要单独写接口取数据，并修改前端用于巡检结果展现，比较繁琐；
• 巡检发现的隐患须要 DBA 主动打开前端查看，再进行处理，影响总体隐患的治理速度；
• ……

因此咱们须要一个灵活、稳定的巡检系统来帮助咱们解决这些痛点，保障数据库的稳定。

2、设计原则

巡检系统的设计原则，咱们从如下三个方面进行考虑：

• 稳定 ：巡检做为保证数据库稳定的工具，它自身的稳定性也必须有所保证；
• 高效 ：以用户为中心，尽可能化繁为简，下降用户的使用成本，让新同窗也能迅速上手治理和管理隐患；提升新巡检部署效率，随着架构、版本、基础模块等运维环境不断变化，新的巡检需求层出不穷，更快的部署等于更早的保障；
• 可运营 ：用数据作基础，对巡检隐患进行运营，包括推动隐患治理，查看治理效率、趋势、薄弱点等。

3、系统架构

美团 MySQL 数据库巡检系统架构图设计以下所示。接下来，咱们按照架构图从下到上的顺序来对巡检系统主要模块进行简单的介绍。

1. 执行层

• 巡检执行环境 ：由多台巡检执行机组成，巡检任务脚本会同时部署在全部执行机上。执行机会定时从巡检 Git 仓库拉取最新的脚本，脚本使用 Python Virtualenv + Git 进行管理，方便扩充新的执行机。
• 任务调度 ：巡检任务使用了美团基础架构部研发的分布式定时任务系统 Crane 进行调度，解决传统定时任务单点问题。Crane 会随机指派某一台执行机执行任务，假如这台执行机出现故障，会指派其余执行机从新执行任务。通常一个巡检任务对应着一个巡检项，巡检任务会针对特定的巡检目标根据必定的规则来判断是否存在隐患。
• 巡检目标 ：除了对生产数据库进行巡检之外，还会对高可用组件、中间件等数据库周边产品进行巡检，尽量覆盖全部会引起数据库故障的风险点。

2. 存储层

巡检数据库 ：主要用来保存巡检相关数据。为了规范和简化流程，咱们将巡检发现的隐患保存到数据库中，提供了通用的入库函数，可以实现如下功能：

• 自动补齐隐患负责人、隐患发现时间等信息；
• 入库操做幂等；
• 支持半结构化的巡检结果入库，不一样巡检的隐患结果包括不一样的属性，好比巡检 A 的隐患有“中间件类型”，巡检 B 有“主库 CPU 核数”，以上不一样结构的数据都可解析入库；
• 针对表粒度的隐患项，若是分库分表的表出现隐患，会自动合并成一个逻辑表隐患入库。

巡检脚本 Git 仓库 ：用来管理巡检脚本。为了方便 DBA 添加巡检，在系统建设过程当中，咱们增长了多个公共函数，用来下降开发新巡检的成本，也方便将老的巡检脚本迁移到新的体系中。

3. 应用层

集成到数据库运维平台 ：做为隐患明细展现、配置巡检展现、管理白名单等功能的入口。为了提升隐患治理效率。咱们作了如下设计。

• 隐患明细展现页面会标注每一个隐患出现的天数，便于追踪隐患出现缘由。
• 配置新的巡检展现时必需要同时制定隐患解决方案，确保隐患治理有章可循，避免错误的治理方式致使“错上加错”。

隐患运营后台 ：这个模块主要目的是推动隐患的治理。

• 运营报表，帮助管理者从全局角度掌握隐患治理进展，报表包括隐患趋势、存量分布、增量分布、平均治理周期等核心内容，进而由上到下推进隐患治理；报表数据一样是经过 Crane 定时任务计算得到。
  = 隐患治理催办功能，用来督促 DBA 处理隐患。催办内容中会带有隐患具体内容、出现时长、处理方案等。催办形式包括大象消息、告警，具体选用哪一种形式可根据巡检关键程度作相应配置。

外部数据服务 ：主要是将巡检隐患数据提供给美团内部其余平台或项目使用，让巡检数据发挥更大的价值。

• 对接先知平台，美团 SRE 团队开发的主要面向研发人员（下称 RD）用户的风险发现和运营平台，平台接收各服务方上报的隐患数据，以 RD 视角从组织架构维度展现各服务的风险点，并跟进 RD 处理进度。巡检系统会把须要 RD 参与治理的隐患，好比大表、无惟一键表等，借助先知平台统一推送给 RD 进行治理。
• 运维周报，主要面向业务线 RD 负责人和业务线 DBA，以静态报告形式展现业务线数据库运行状况以及存在的问题，巡检隐患是报告内容之一。

4、巡检项目

巡检项目根据负责方分为 DBA 和 RD，DBA 主要负责处理数据库基础功能组件以及影响服务稳定性的隐患。RD 主要负责库表设计缺陷、数据库使用不规范等引发的业务故障或性能问题的隐患。也存在须要他们同时参与治理的巡检项，好比“磁盘可用空间预测”等。目前巡检项目共 64 个，类目分布状况以下图所示：

• 集群 ：主要检查集群拓扑、核心参数等集群层面的隐患；
• 机器 ：主要检查服务器硬件层面的隐患；
• Schema/SQL ：检查表结构设计、数据库使用、SQL 质量等方面的隐患；
• 高可用 / 备份 / 中间件 / 报警 ：主要检查相关核心功能组件是否存在隐患。

下面，咱们经过列举几个巡检任务来对巡检项作简单的说明：

5、成果

美团 MySQL 巡检系统已稳定运行近一年时间，基于新巡检体系上线的巡检项 49 个。经过巡检体系持续运行，在团队的共同努力下，咱们共治理了 8000+ 核心隐患，近 3 个月隐患治理周期平均不超过 4 天，将隐患总数持续保持在极小的量级，有效地保障了数据库的稳定。

下面的隐患趋势图，展现了近一年中隐患的个数，数量忽然增加是因为新的巡检项上线。从总体趋势上看，隐患存量有很是明显的降低。

除了推进内部隐患治理以外，咱们还经过对接先知平台，积极推进 RD 治理隐患数量超过 5000 个。

为了提高用户体验，咱们在提高准确率方面也作了重点的投入，让每个巡检在上线前都会通过严格的测试和校验。

对比其余先知接入方，DBA 上报隐患在总量、转化率、反馈率几个指标上都处于较高水平，可见咱们上报的隐患风险也获得了 RD 的承认。

指标说明：

• 反馈率 = 截止到当前时刻反馈过的风险事件数量 / 截止到当前时刻产生的风险事件总量 * 100%；
• 反馈准确率 = 截止到当前时刻反馈准确的风险事件数量 / 截止到当前时刻反馈过的风险事件总量 * 100%；
• 转化率 = 截止到当前时刻用户反馈准确且须要处理的风险事件数量 / 截止到当前时刻产生的风险事件总量 * 100%。

6、将来规划

除了继续完善补充巡检项之外，将来巡检系统还会在如下几个方向继续探索迭代：

• 提升自动化能力，完善 CI 和审计；
• 增强运营能力，进一步细化每一个隐患的重要程度，辅助决策治理优先级；
• 隐患自动修复。