提质增效：去哪儿网数据库巡检报警系统优化之路

原创去哪儿DBA团队 Qunar技术沙龙

一前言
二巡检系统优化历程

2.1 面对的问题
2.2 优化之路

2.2.1 优化方案设计
2.2.2 方案实施

三告警系统优化历程

3.1 面对的不足
3.2 优化之路

四优化效果
五未来展望

作者介绍

刘鹏飞，2021年4月加入去哪儿网DBA团队，主要负责公司的MySQL的管理和运维，以及数据库的自动化平台开发。具有多年的数据库管理和优化经验。

一前言

告警系统在数据库管理中扮演着至关重要的角色。它通过实时监测系统状态，一旦发现异常或达到预设条件，便迅速生成警报，确保相关人员能够及时得到通知并采取相应措施。

在去哪儿网的运维保障工作中，告警系统发挥了巨大作用，显著提高了故障发现和处理的效率。然而，仅仅依赖告警系统是不够的。在日常的数据库管理中，潜在的风险和问题可能悄然滋生，难以仅通过告警来全面掌握。因此，巡检系统成为了不可或缺的补充。

巡检系统通过对应用程序的性能和运行状态进行全面评估，能够及时发现潜在风险并提前解决萌芽阶段的问题。这使得DBA能够更加从容地应对复杂的数据库环境，提高整体服务质量。

为了进一步提升运维保障工作的效率和品质，去哪儿网DBA团队在数据库巡检系统和告警系统中采取了一系列优化措施。这些措施包括改进监控机制、健全指标及其等级分类、增强自动化处理能力、完善巡检指标、自动生成报告等。通过这些优化手段，去哪儿网不仅提高了数据库的稳定性，还显著减少了故障发生的风险，为公司的业务发展提供了坚实的技术保障。

二巡检系统优化历程

2.1 面对的问题

原巡检系统虽然在一定程度上能够检测并报告主机的磁盘使用情况和集群实例的表和索引相关问题，如表大小、表碎片率和冗余索引等。

然而，它存在一些严重缺陷，导致无法全面评估集群实例的性能和负载情况，也无法准确判断集群实例的风险等级。

原巡检系统在巡检内容上过于狭窄，仅涵盖了主机层面的磁盘使用情况和集群实例的表和索引相关问题，而忽略了集群实例负载和性能相关的关键指标。这意味着系统无法及时发现潜在的性能瓶颈或负载问题，从而无法提前预警或采取措施来避免潜在的风险。
原巡检系统缺乏对巡检上来的信息进行风险等级划分的机制。这导致用户无法准确判断集群实例的风险程度，以及风险点在哪里，风险等级是高还是低。这样的缺陷使得用户无法采取针对性的措施来降低或消除风险，从而可能对系统的稳定性和可用性造成严重影响。

因此，为了提高巡检系统的全面性和准确性，需要对原巡检系统进行改进和完善。

首先，需要扩展巡检内容，增加对集群实例负载和性能相关指标的检测和评估。
其次，需要引入风险等级划分的机制，以便准确判断集群实例的风险程度和风险点，从而采取相应的措施来降低或消除风险。

这样的改进将有助于提高系统的稳定性和可用性，确保集群实例的安全和高效运行。

2.2 优化之路

2.2.1 优化方案设计

针对原巡检系统存在的问题和不足，我们主要从以下四个方面进行优化和升级：

指标健全

首先要明确我们日常巡检想要发现哪些问题，其次再梳理出哪些指标能暴漏出这些问题，最后将这些指标加入日常巡检任务，主动收集上报到巡检平台。

通过以上的梳理，我们增加了几十项重要指标，涵盖了主机层的CPU负载、网卡流量和内存使用等，以及MySQL数据库层面的长事务、锁和活跃线程并发等，还有Redis层面的CPU使用率、网络流入（出）带宽等。

指标分类

指标分类是根据每个巡检指标的含义，将它们按照能够体现集群实例不同方面的问题进行分类。这些分类包括QPS（每秒查询率）、活跃线程并发等。

通过指标分类，可以更好地理解集群实例的性能和问题所在，从而采取相应的优化措施。

指标分级

为了更好地管理和监控指标，我们需要对它们进行分级。

首先，我们需要为每个指标设定高中低风险的基准线。这些基准线可以根据历史数据、业务需求以及其他相关信息来确定。例如，对于某些关键业务指标，我们可能会将其风险基准线设定得相对较低，而对于一些非核心业务指标，我们可能会将其风险基准线设定得相对较高。

在确定了指标的风险基准线后，我们需要根据指标的重要性为其赋予不同的权重比。重要性可以基于异常带来的影响来评估。例如，对于一些关键的业务指标，如流控类指标，由于其对于业务正常运行至关重要，因此权重较高。相反，对于一些非核心的业务指标，如实例访问量（QPS）异常，由于其对于业务的影响相对较小，因此权重较低。

通过这种方式，我们可以对各个指标进行合理地分级和权重分配，从而更好地识别和应对潜在的风险。这有助于提高业务的稳定性和可靠性，降低潜在的损失。同时，这种分级和权重分配的方法还可以帮助我们更好地分配资源，优化监控策略，提高运营效率。

综合研判

根据巡检指标的数值，对每个单项指标进行风险等级判定。这需要考虑指标的具体数值、变化趋势以及与历史数据的对比。然后将各个单项指标的风险等级进行综合计算，得出实例级的风险得分和风险等级。

最终我们将形成两份报告。一份是单项指标风险报告，详细列出每个单项指标的风险等级、得分和可能的影响因素。这份报告旨在帮助 DBA 了解各指标的具体风险情况，从而采取相应的措施进行优化或改进。另一份是实例风险报告，汇总了实例级的风险得分和风险等级，以及其他相关的综合信息。这份报告提供了一个整体的风险评估结果，帮助 DBA 了解该实例的风险状况。

通过这两个维度的报告， DBA 可以全面了解巡检指标的风险情况，为进一步的风险管理和优化提供有力的数据支持。

2.2.2 方案实施

通过 agent 采集到各种指标数据后，server 端会对上报上来的数据进行计算分析，最终形成巡检报告。

比较有代表性的报告，包括但不限于实例级巡检报告、活跃线程巡检报告、慢查询巡检报告、QPS 巡检报告和数据库扫描行数巡检报告。

实例级巡检报告

实例级巡检报告主要来判定集群和实例是否存在风险，以及风险达到的程度，并且在实例级风险报告中会按照风险项的风险等级对具体风险项进行排名。DBA 通过该巡检报告能快速知道应该从哪个方向入手进行风险的具体排查和优化，从而高效地消除风险。

活跃线程巡检报告

活跃线程巡检报告是针对数据库状态指标 Threads_running 进行分析并计算相关风险得出的巡检报告。MySQL 数据库通过 innodb_thread_concurrency 参数（官方给出了不同情况下不同建议）的设置来限制 Innodb 并发线程的数量，一旦并发线程的数量达到这个限制，其他线程就会进行休眠，然后被放入等待队列。这种情况下最直观的表现就是，那些正常情况下执行很快的 SQL ，执行时间会增加，甚至于出现在慢查询日志，使用该实例的应用响应时间会相对增加。

为了能快速定位 Threads_running 过高导致的数据库性能问题，对 processlist 进行特别的监控：

agent 端每隔 2s 循环抓取 information_schema.processlist 的数据，去除特定状态的线程后，总数据量和 Threads_running 状态值就能相互对应；
若上面抓取数据的总量超过设定的阈值就将抓取的 information_schema.processlist 信息全量的推送到巡检记录数据库；
server 端循环分析上报上来的 information_schema.processlist 信息：计算 SQL 指纹和 MD5 值-->按照 MD5 直进行 SQL 分类-->计算出 SQL 总执行时间和最大执行时间；
分析结果呈现，形成报告：
① 巡检报告汇总：可以对部门、集群、实例等进行筛选。
②具体实例的活跃线程记录：可以查看活跃线程异常值和对应的出现时间点。
③活跃线程详情：分析处理哪类 SQL 并发高，总执行时间，最大执行时间等。点击最后一列的查看操作按钮能查看具体 SQL 的执行状态（这里不再展示）。
通过对活跃线程的监控分析能快速定位引起并发异常的问题原因所在，是集群性能下降、慢查询还是应用端没有控制好请求并发导致的问题，一目了然。从而也能很好的回答 DBA 经常被问到一个问题：我的应用日常执行这些 SQL 不慢，人为测试执行一次也非常快，为啥有时突然就成了慢查询？
意外惊喜：通过对活跃线程的监控分析，我们还发现在很多活跃线程异常高的时刻都伴随着删除用户和授权的操作。通过进一步分析发现， MySQL 的删除用户、创建用户、授权和回收权限操作具有较高的优先权，在同一时刻，这些操作会优先被执行，获取线程资源。去哪儿网 MySQL 数据库用户授权方式使用的是具体 IP 授权，在每次应用发布和扩容时都会伴随着大量的删除用户、创建用户和授权操作，这些操作就会导致 MySQL 的线程资源短时无法被正常应用获取到，从而导致活跃线程异常升高的现象。为此，我们和 TC 组合作进行了授权方式的改造和优化，消除了这种情况导致的异常。

慢查询巡检报告

慢查询巡检报告是通过自动分析慢查询日志，生成慢查询日报、周报等。慢查询平台可以查看哪类慢查询执行时间最长、每天的执行次数等，并能给出慢查询的优化建议。

通过自动分析，我们还对慢查询进行了分类，从执行时间、影响行数、扫描行数等几个维度生成不同的子报告，多维度地高效分析慢查询带来的影响。

数据库扫描行数巡检报告

数据库扫描行数巡检报告是通过分析查询 SQL 扫描行数和 DML 影响行数来判定其风险等级。另外通过数据库扫描行数和 QPS 进行对比，可以初步判定是否有大查询和更新，或者是否有些 SQL 可以加缓存来降低数据库的请求。

三告警系统优化历程

3.1 面对的不足

之前的告警系统能满足基本的日常告警需求，但是也存在几个比较突出的问题：

无效告警繁多：虽然对告警项做了分级，但是依然会发送告警消息，导致消息太多，造成日常干扰。
动态调整低效：在计划性维护前，对数据库告警不能进行有效的事前静默，且告警屏蔽维度设置不足。
自动化覆盖率低：对于异常告警不能抓取问题时刻的现场信息，不能自动分析原因，导致告警处理速度较慢，问题定位有时会出现偏差。
告警报表缺失：没有一个成熟的告警平台展示告警数据的变化趋势，多维度统计分析告警分布情况。

3.2 优化之路

针对告警系统的不足，参考其他告警系统的优势，对我们的告警系统采取了三个方向的优化：

（一）告警降噪

分级处理
重新设定告警阈值，将告警项根据不同的阈值依然划分成 WARNING，CRTICAL 和 CALL 级别，对于 CALL 级别以下的告警，仅做记录，不再发送消息，而对 CALL 级别告警会通过 QT 消息和电话两个通道进行通知，从而减少 CALL 级别以下的无效告警通知，提高了值班人员对重要紧急告警的专注度和处理速度。
动态屏蔽
在一些计划维护，故障处理等场景中，可以对集群、实例、特定告警项设置告警屏蔽起止时间，屏蔽时长等，消除了计划性维护时和故障处理期间的“无效”告警。
定制阈值
不同应用使用数据库会有些许区别，且高峰时间段也不尽相同，所以优化后的告警系统，能对集群或者实例告警项的阈值和生效时间灵活设置。

（二）告警处理

一键拉群
在告警通知卡片中点击“一键拉群”，可以自动创建 Qtalk （内部办公IM软件）群聊，并将告警信息和分析结果发送到相应群聊里。
自动处理
部分告警项根据告警内容设置自愈方案，只需 DBA 确认即可，无需过多人工介入。如主从复制中断的一些场景，磁盘可用空间不足的场景，慢查询和长事务查杀的场景等。
根因分析
对于不同的告警项设置不同的自动抓取规则，在告警时刻会对实例的状态指标和运行的 SQL 自动抓取和分析，并将分析结果呈现到告警卡片中。
其主要实现如下：

告警问题分类：根据告警项监控内容将告警分类，从而指定不同的信息采集规则；
实例信息采集：根据告警项命命中的采集规则，采集实例相应的状态参数和当前线程执行情况 SQL 的状态；
状态自动分析：将采集到的信息进行综合分析，判断可能的问题原因。是 PXC 流控导致，还是半同步退化导致，亦或长事务或者锁等待导致等；
分析结果呈现：将分析结果以报告形式呈现给 DBA ，协助 DBA 进行处理。在告警卡片中 DBA 点击相应按钮即可查看分析报告。

去哪儿网的 MySQL 集群大量的使用 PXC 架构，集群发起流控或者某一个节点性能严重抖动时，集群中的其他节点性能也就会受到严重影响，造成性能急剧下滑，自动根因分析功能能高效的识别这种情况，避免了 DBA 繁琐的去分析各个节点的指标来查找原因。

（三）告警运营

告警检索：告警平台提供了历史和当前告警的检索功能，支持按不同条件查询告警信息的需求

告警看板：通过对所有告警的聚合分析，告警平台支持了从不同视角展示告警数据的变化趋势，多维度统计分析告警分布情况。

另外告警运营相关功能和数据库巡检形成相互补充，进一步提高数据库日常风险排查效率。

四优化效果

通过优化巡检系统和告警系统，我们取得了显著的效果。

首先，我们成功消除了无效告警，从而提高了告警的准确性和接手率。这不仅减轻了值班DBA的工作负担，还让他们能够更专注于处理真正的告警问题。

其次，通过对巡检系统所暴露出来的风险进行深入分析，我们针对数据库进行了相关优化，并促进了应用程序的进一步优化。这使得告警总量减少了95%以上，这是一个非常显著的数字，表明我们的优化工作取得了巨大的成功。

再次，在巡检系统和告警系统中加入自动化分析功能，使我们的分析效率提升了90%以上。这意味着我们能够更快地发现问题并采取相应的措施。告警处理时间也大幅降低，现在可以迅速地定位并解决问题，甚至在分钟或秒级别内完成。

最重要的是，数据库的稳定性得到了显著提高，实现了线上零故障的目标。这不仅提高了DBA的工作效率，也极大地提升了DBA的工作口碑。业务线对我们的服务也给予了高度的认可和评价，也让DBA团队更有信心为数据库的稳定运行提供更加强有力的保障。

五未来展望

持续提升处理效率：丰富自动根因分析的使用场景，持续优化相关分析规则，从仅在数据库实例层的分析扩展到相关主机层的自动分析，为故障定位提供更多的因素参考，并增加一定的自动处理和优化措施，从而使故障处理效率再次提升。
告警降噪：根据集群中实例之间的关系，告警可以进行合并，减少冗余信息，可以更加清晰地了解数据库集群各个节点的健康状态，快速定位问题所在。
提升告警配置效率：借助DBA自助机器人功能，告警配置可以变得更加智能化和高效，甚至可以根据不同的集群情况实现不同阈值的定制化配置，大大提高了配置效率和准确性。