告警数量减少95%：去哪儿数据库巡检报警系统做了哪些优化？

背景

挑战

首先，我要谈谈去哪儿数据库团队所面临的三个主要问题：

1. 实例状态不明：去哪儿网目前运行着大约2000+套MySQL和Redis集群，背后是将近2万个实例。面对如此庞大的集群和实例数量，怎么快速掌握哪些集群（实例）有风险？风险点在哪？什么时间段存在风险波动？这种不透明性给我们的运维工作带来了极大的挑战。
2. 无效信息繁多：尽管我们已经建立了一些巡检和告警机制，但由于告警的标准不明确，造成告警或者巡检信息繁多，很多都不是重要或者需要紧急处理的，而重要信息却又淹没在了信息海洋里。
3. 问题排查耗时：当我们面对大量的巡检信息、告警信息以及其他反馈信息时，人工分析变得非常耗时。此外，问题的关键时刻常常缺少重要信息。有些抖动或异常可能仅发生在几秒钟内，一旦错过那个关键时间点，在没有有效的信息记录的情况下，就很难再分析出具体原因，这对于监控和问题定位都是一大难题。

尤其是在节前高峰等重要时间点，提前进行风险和容量评估等工作显得更为重要和紧急，而如何利用巡检信息进行综合研判也就显得更有价值。

目标

为了解决这些问题，我们采取了分阶段优化的方法，包括事前巡检、告警的及时发出、以及快速处理等策略。

1. 明晰实例状态：首先要制定一个巡检标准，通过这个标准对巡检项进行风险等级划分，然后综合形成巡检报告，报告中指明巡检项目是不是存在风险，相应实例和集群有没有风险，风险的等级是什么。通过明确风险等级的巡检就指明了相应的优化方向。
2. 精简信息，突出重点：我们的目标是消除90%以上的无效信息，提高告警接收率到百分之百。电话告警和发出的消息，一定要是需要第一时间响应，第一时间处理的。
3. 快速定位，快速处理：提高巡检效率到80%以上，确保巡检上来的指标能够明确问题所在。同时，要借助自动化工具，平均将故障定位和处理时长缩短50%以上。

通过这些措施，希望能够更高效地进行数据库运维工作，确保去哪儿网的数据库服务稳定而可靠。接下来，我将详细介绍巡检报警系统优化方面的具体措施和成效。

一、DBA团队对巡检系统做了哪些优化？

1.1 存在的不足

在巡检系统的优化过程中，我们发现了四个主要的不足之处：

1. 指标不全：巡检指标缺少了一些重要的巡检项，导致部分风险无法有效暴露出来。
2. 标准不明：缺少一个明确的风险等级标准，使得巡检出来的结果仅仅是数字，缺乏具体意义。
3. 信息不足：在关键时刻，抓取的实例信息不足，如故障时刻数据库的并发状态，执行的SQL状态等。这些关键信息的不足就导致了问题排查和原因定位比较困难。
4. 分析低效：缺少自动化分析工具，导致许多分析工作需要人工进行，不仅耗时有时也会出现较大偏差。

1.2 优化步骤

1.2.1 优化步骤1: 指标健全和分类

我们首先对指标进行了梳理，明确了需要健全的指标。在主机层面，主要关注四个方面：CPU、内存、网络和磁盘。具体来说，监控CPU使用率、内存的Free空间、网络的流入流出带宽、磁盘的IO以及剩余空间等。

对于MySQL，我们不仅关注实例层面性能指标，还会关注集群层面的性能指标。例如实例层面关注的有慢查询情况、线程并发的高低、锁的等待情况以及表的状态等。在集群层面，关注PXC集群的节点状态，包括节点的在线状态、是否有流控，QMHA集群的节点在线状态、半同步状态和复制状态。这里需要说明的是，如果集群中的节点不在线，业务是无法连接到集群的。

此外，对于Redis，我们同样关注单实例和集群指标，如内存使用、连接数、CPU使用率和网络流量。还会检查集群的分片是否存在热点Key，内存分布是否均匀，以及是否满足跨机房的需求。

这里仅列举了一些场景的重要指标，并不全面，仅供大家参考。

1.2.2 优化步骤2: 指标分级

在指标健全之后，需要对巡检结果进行分级。根据每个指标的历史数据、业务需求、经验和其他相关信息，我们为每个指标设定了高中低风险的基准线，从而使每个指标的巡检结果都能得到合理的分级。

此外，还需要确定各个指标的重要性，并赋予它们不同的权重。例如，对于PXC集群，流控对集群的性能影响最大，因此流控指标的权重比较高。同样，如果并发数高，它将影响整个集群的性能，因此并发数的权重也会很高。这种重要性的评估是基于异常带来的影响来进行的。通过合理的分级和权重分配，我们可以更好地识别和应对潜在的风险，从而提高日常巡检的工作效率。

1.2.3 优化步骤3:综合研判

在确定了指标的风险等级和权重之后，会形成一个风险报告。这个风险报告可以明确指出实例的风险是什么，集群的风险是什么，以及它们的风险水平如何。例如，我们可以为集群实例级的风险等级提供一个报告，还可以为单项巡检指标，如扫描行数、活跃线程数、QPS请求、慢查询、长事物等，提供相应的风险报告。

1.3 具体实践场景

1.3.1 实践场景一：为什么日常执行很快的SQL会变慢？

场景说明：

这个问题对于DBA来说是一个常见的挑战。我们需要考虑的是，哪些因素可能导致SQL查询变慢。经过分析，我们发现以下几个主要因素：

1. 业务请求并发高：当业务请求的并发量增高时，可能会导致SQL查询变慢。
2. 半同步退化：如果使用了半同步复制，其退化也可能导致SQL执行速度瞬间下降。
3. 锁等待：查询中的锁等待也是导致SQL变慢的一个重要因素。
4. 批量授权操作：进行批量授权操作时，也可能会导致SQL查询速度下降。
5. PXC限流：PXC集群在发生流控的情况下，也会导致SQL执行速度下降。

这些问题通常都与并发量有关，无论是正常请求还是异常请求，都会反映在并发量的异常上。目前去哪儿网MySQL数据库并发设置innodb_thread_concurrency是24，当业务并发超过这个限制时，就会出现线程排队现象，从而导致SQL查询变慢。

解决方案：

为了解决这些问题，我们实施了一个活跃线程的巡检方案。具体做法如下：

循环监测活跃线程：每两秒钟监控一次数据实例的活跃线程数。

信息抓取：一旦活跃线程数超过设定的阈值，就会自动抓取线程执行的信息，并将其记录下来，上报至数据库。

自动分析：我们有一个自动分析工具，它会对抓取上来的信息进行自动分析，识别出是哪一类SQL的并发高，总并发是多少，这一类SQL的平均执行时间以及最慢的SQL是哪些等。

生成报告：最终，这些分析结果会形成一份巡检报告，便于DBA和相关开发人员查看。

如图是我们开发的一个页面，它能够展示数据库实例在不同时间点的活跃线程指标。这个页面可以让我们快速了解到，在任意给定的时间点，数据库的活跃线程达到了什么水平。

1.3.1 图3 - 页面效果展示-Top20活跃连接数

进一步点击进去，我们能够看到每一个时刻抓取到的信息，并且这些信息都经过了分类处理。能够清晰地看到，哪一类SQL的占比最高，这类SQL的平均执行时间是多少，以及最大执行时间是多少。甚至可以具体了解到，某个具体的SQL的执行情况如何。

1.3.1 图4 - 页面效果展示-具体SQL的平均执行时间是多少

1.3.1 图5 - 页面效果展示-具体的SQL的执行情况如何

应用效果：

通过捕获这些活跃线程的信息，能够解决许多常见的问题。例如，我们经常遇到的问题是，应用程序突然间遭受性能损失，这很可能是因为应用那边没有做并发限制。此外，我们还解决了一个重大的问题，那就是数据库的授权方式。

之前，我们的授权方式是基于具体IP的，一个应用发布可能需要数百甚至上千个容器来进行授权，这种批量操作的规模是相当大的。当这些授权操作集中发生时，数据库的线程很容易被打满，从而导致其他正常请求的SQL查询变慢。

我们曾经花费很长时间去分析这个问题，但始终无法找到原因，因为在慢查询日志中并没有看到相关的信息。这个问题困扰了我们很长时间。后来，我们开始监控和分析活跃线程信息，发现一些数据库虽然请求不多，几乎没有慢查询，但仍然存在慢查询的问题。这些数据库的共同特点是，它们一直在执行授权操作，比如drop user和grant user等。

通过深入调查和分析，最终确认了这些授权操作是导致慢查询的原因。这个发现促使我们改进了数据库的授权方式，使得新的授权方法比旧的方法更加安全，无论是对数据库本身，还是对应用层面，乃至整个系统安全性都带来了显著的提升。

1.3.2 实践场景二：拿到巡检报告后如何快速定位问题？

场景说明：

例如，在某个时间段内，可能存在以下指标异常，如 主机磁盘IO升高或者网络带宽使用异常升高或数据库扫描行数指标异常升高等。

面对拿到的异常巡检报告，我们常常感到无从下手，因为分析这些数据可能会非常复杂和耗时。其实最有帮助的信息很多都藏在慢查询日志里，那么应该如何有效地分析慢SQL日志，以便快速定位并解决问题呢？

解决方案：

在处理数据库性能问题时，慢查询日志是我们最常用的工具之一，它主要包含以下信息。

通过对这些指标的分析，可以判断DML语句更新量，哪些SQL是最消耗资源的，哪些SQL对磁盘I/O和CPU的效率要求较高，以及SQL在执行过程中持有锁的时间。

为了更高效地分析慢查询日志，我们开发了一个自动化的分析工具。它可以对SQL计算指纹SQL和指纹MD5，进而进行归类。计算每个分类中SQL的总扫描行数、查询时间、发送的数据量等，并得出总和与平均值。然后根据这些计算结果，生成不同指标的分析文件。

通过这些分析文件，可以快速定位问题。例如，可以识别出哪些SQL对网络带宽的消耗最高，哪些SQL的扫描行数最多，从而最消耗资源。

案例分析：

在某一次火车票业务的压测过程中，我们注意到，在正常运行时，该业务的扫描行数并不高，慢查询也很少。但在压测期间，发现扫描行数突然增加了很多倍，同时QPS也显著增加，尽管如此，慢查询的数量并没有增加。

我们首先调整了慢查询阈值，进行了更为细致的监控和分析。我们发现，虽然涉及的是一些小表，但由于查询的QPS很高，这些小表的查询操作对数据库造成了较大的压力。通过自动化分析工具，生成了一份详细的报告，报告中可以看到总扫描行数最高的SQL语句，而这些就是影响性能的关键点。

拿到这份报告后，可以进一步确认具体是哪些SQL语句导致了性能问题。随后，我们将这些分析结果和优化建议反馈给研发团队。建议他们在这些经常执行的SQL语句上增加缓存，以减少对数据库的直接访问。

研发团队采纳了我们的建议，通过引入缓存机制，有效地降低了数据库的负载，解决了性能瓶颈问题。

二、数据库告警系统做了哪些优化？

2.1 劣势缺点

报警系统作为关键一环，它的优化同样至关重要。我们的报警系统存在四个主要问题：

1. 无效告警太多：尽管之前已经实施了告警分级，但在策略制定和信息发送方面还有待改进，导致了大量的无效告警产生。
2. 动态调整低效：现有的系统不能有效地进行事前静默，而且在效率上也不尽人意。例如，当我需要维护一个集群，而该集群下有多个实例时，我很难快速地屏蔽掉所有实例的某个特定告警项。同样，当我需要对某个实例进行关机维护时，现有的系统也不能便捷地屏蔽掉该实例的所有告警。
3. 自动化覆盖率低：目前的自动化系统不能有效地自动分析现场信息，这导致告警处理速度较慢，有时甚至会造成问题定位的偏差。
4. 告警报表缺失：无法直观地展示哪些告警已经恢复，哪些还没有恢复，以及哪些实例或集群的告警项较多。

我们需要一个更加智能、更加高效的报警系统，以帮助更好地管理数据库的性能和稳定性。

2.2 优化措施

2.2.1 告警降噪

1）分级处理

首先，我们对告警进行了重新分级处理。正如大家所知，告警分级在很多公司都有实施，通常分为Warning、Critical等级别。每个公司的分级标准可能有所不同，我们对现有的告警分级进行了重新梳理，并采用了不同的消息通知策略。

例如，对于某些Critical级别的告警，我们可能不再需要实时发送通知，而是记录下来，然后自动分析形成一个报告。这样，大大减少了无效告警信息的产生，对于值班人员来说，他们可以更专注于处理重要的告警，提高了他们的工作效率和响应速度。

2）动态屏蔽

我们希望能够对集群实例的特定告警项设置告警屏蔽的起始时间。特别是在Redis集群发生故障时，告警量可能会急剧增加，此时需要的是能够一键屏蔽掉所有的告警。

比如，假设一个集群有几十个实例，当Redis突然间负载变高，所有实例都会告警，作为值班人员来说，一边要处理问题，一边还要接告警电话，极其影响告警处理效率。

3）定制阈值

根据集群和实例的重要程度，我们可以选择使用通用模板或者设置特定的个性化阈值。对于一些不太重要的集群，可能需要调低阈值，而对于更重要的集群，则需要更敏感的设置。

在主机级别，也可以实现全部告警项的屏蔽，或者某一特定告警项的屏蔽。这一点，无论是在集群级别还是实例级别，我们都能做到。因为我们的集群都有特定的名称，通过这些名称，可以快速地获取到对应的实例信息，实现一键式的告警屏蔽或者精细控制的设置。

2.2.1 图3 - 根据需要灵活进行告警屏蔽设置

2.2.2 告警处理

1）一键拉群

这个功能允许快速地将告警信息和分析结果发送到相应的群里。每个集群都有其对应的应用，而这些应用都有各自的负责人。通过一键拉群，可以迅速地将相关负责人聚合在一起，以便及时响应和处理告警。

2）自动处理

对于某些类型的告警，比如主从复制问题或慢查询，我们设置了一系列自动化处理方案。在很多情况下，这些告警只需要DBA确认一下即可，无需过多的人工介入。这样的自动化处理不仅提高了工作效率，也减少了告警的响应时间。

3）根因分析

我们首先会对告警问题进行分类，然后根据告警内容采集相应的信息。例如，如果是主从相关的告警，我们会采集主从相关的指标；如果是PXC集群相关的告警，我们会采集PXC相关的信息。这样，就能对告警进行准确的分类，并采集到有用的信息。

接下来，会根据告警项采集实例的实时信息，包括当前的状态参数和线程信息。

然后，会对采集到的信息进行自动分析，判断可能存在的问题原因。比如，我们会分析是不是流控导致的主节点性能抖动，还是并发过高导致的。

最后，会将分析结果以页面的形式呈现给DBA，协助他们进行处理。

应用案例-1：

当接到一个告警，我们查看慢查询或者集群状态等信息，迅速知晓告警产生的原因方向，是慢查询引起还是集群发生了流控等。

2.2.2 图2 - 通过告警分级进行具体分析

在进入去哪儿网之前，我并未接触过PXC集群，很少去分析主节点的性能抖动。当抖动发生时，我可能会关注一个正常的业务请求是否有慢查询，很多时候会忽略它是否有流控。当一个告警出现时，如果流控是偶发的，情况可能还不严重。但如果流控持续存在，就要求有能力快速判断，具体是哪个节点，是什么原因导致的流控。

很多时候，流控可能是由于写入量过大或节点性能下降导致的，而性能下降往往是慢查询引起的。因此，我们会特别关注流控节点上的SQL执行情况，分析是否存在慢查询。还会统计告警节点的线程状态。通过分析线程状态，可以判断出导致问题的具体原因。

我们还遇到过一个案例，涉及到Opentables参数设置不当的问题。最初，我们以为问题可能与慢查询或其他因素有关。但通过对线程状态的深入分析，最终确认问题是由于Opentables参数设置过小导致的。在这个案例中，我们通过抓取线程信息，分析其状态，从而确定了问题的根源。

应用案例-2：

此外，在处理主从复制的问题时，也曾遇到过IO线程或SQL线程突然中断的情况。如果自动化处理不当，可能就需要手动重启复制，这无疑增加了工作量。

实现了自动化操作之后，通过检查半同步相关的状态参数和设置，就可以快速定位并解决问题。有时，半同步退化也会导致主节点性能的突然抖动，这是我们在集群管理中的经常遇到的。

2.2.2 图3 - 主从复制自动重启

2.2.3 告警运营

我们的目标是将收集到的各类告警信息，如Warning和Critical级别的告警，进行综合分析。

1）告警检索

我们首先实现了告警检索功能，允许用户根据告警项、主机或实例等条件进行历史和当前告警的查询。

2）告警看板

此外，引入了告警看板，它能够对所有告警进行聚合分析，并从不同视角展示告警数据的变化趋势。通过多维度的统计分析，可以更好地了解告警的分布情况。例如，可以提供主机实例的告警统计报告，帮助我们了解哪些主机或集群实例的告警数量较多。

告警看板与巡检系统形成了互补。有时候，巡检报告可能未能发现的问题，通过告警看板却能被发现，相当于增加了一个风险排查的手段，这样就提高了日常风险排查的效率。

2.2.2 图1 - 对告警情况进行排序，找出告警项占比最多的集群或主机

2.2.2 图2 - 查询特定告警的持续时间、告警屏蔽情况、告警分布等

三、总结与展望

3.1 落地效果

整体来说，我们的优化取得了显著的成效，大幅减少了工作中的盲点。

• 基本消除无效告警和无效巡检信息
• 整体告警总量减少95%以上
• 分析效率提升90%
• 告警处理时间降低至分钟级，甚至秒级
• 数据库稳定性提高，线上零故障

3.1 图1 - 近三年Call告警总量月度统计对比

通过查看近三年来的告警量变化，告警量有大幅度的降低，可见我们的优化工作是非常有效的，尤其是在业务量恢复并超过往年的情况下，数据库风险告警量仍然得到了有效降低。我们也注意到，告警量的波动与高峰期有关，例如在五一、十一等假期前，告警量也有所下降，这一趋势更好地反映出了优化措施的成效。

3.2 未来规划

目前，自动化分析系统还有一些提升空间，尤其是在准确率方面。为此，我们计划深化运维经验，构建更加完善的自动化分析流程，以减少人工介入，提升分析的准确性。

我们的目标是实现更高程度的自动化操作，比如通过手机或网页端简化日常任务。同时，也将改进问题的跟踪记录，让DBA能够更便捷地访问和审查集群的历史信息，包括之前的问题记录和业务关联情况。这将帮助DBA更好地掌握集群状态，做出更明智的决策。（全文完）

Q&A:

1、准确率这块，能否分享一些告警相关性分析和聚合的具体方法或技术？

2、在监控数据库并发和锁竞争时，使用了哪些具体的技术或指标？

3、怎么自动化生成和分发数据库巡检报告？不同的使用团队有没有特定的模板或格式？

4、实现告警阀值的自动调整，是有一个自适应的反馈机制、根据历史数据和系统负载动态调整阔值吗?

以上问题答案，欢迎点击“阅读全文”，观看完整版解答！

！！重要通知！！

如果你在某个稳定性领域有深入研究和实践，或者是技术团队的管理人员。欢迎加入TakinTalks稳定性社区专家团，以演讲、文章、视频等形式传播你的最佳实践和经验。有意可联系社区工作人员 18958048075（乔伊，微信同号）。