本文由 dbaplus 社群授权转载。

一、背景

2017年以前我们运维体系的监控主要还是以Zabbix作为主流的解决方案（目前已经不是Zabbix了，运维团队基于Open-Falcon定制开发了一套统一的运维监控系统，当然这是后话了）。当时数据库这部分的监控服务也是使用的监控运维团队提供的服务。总体来说Zabbix的功能还是非常强大的，而且使用也比较简单，基本上写写脚本就能实现指定应用的监控。

我们在2016年就已经尝试MySQL的容器化，2017年开始大规模应用。容器化以后MySQL数量大幅度上升，通过平台化进行管理。原来使用的Zabbix已经无法满足需求：

监控指标太多，如果都接入到Zabbix，服务器无法承受(当时的服务器资源情况下)；
数据库运维平台对监控告警的管理需要联动处理；
数据库运维平台上实例增删时需要监控系统自动发现实例；
有趋势预测、数据快速统计的需求；
对监控指标画图有自定义的需求。

所以我们DB团队内部想选型一款监控系统来支撑以上需求。

二、技术选型

关于数据库的监控，我们并不想投入太多人力去维护，毕竟监控系统不是我们的主要工作。所以需要选一款部署简单、服务器资源占用低、同时又能结合告警功能的监控系统。虽然目前开源的监控系统还是有不少的，但是最终评估下来，还是选择了更轻量化的Prometheus，能够快速满足我们数据库监控的需求。

1、易用性

二进制文件启动、轻量级server，便于迁移和维护、PromQL计算函数丰富，统计维度广。

2、高性能

监控数据以时间为维度统计情况较多，时序数据库更适用于监控数据的存储，按时间索引性能更高，数百万监控指标，每秒处理数十万的数据点。

3、扩展性

Prometheus支持联邦集群，可以让多个Prometheus实例产生一个逻辑集群，当单实例Prometheus Server处理的任务量过大时，通过使用功能分区(sharding)+联邦集群(federation)可以对其进行扩展。

4、易集成性

Prometheus社区还提供了大量第三方实现的监控数据采集支持：JMX， EC2， MySQL， PostgresSQL， SNMP， Consul， Haproxy， Mesos， Bind， CouchDB， Django， Memcached， RabbitMQ， Redis， Rsyslog等等。

5、可视化

自带了Prometheus UI，通过这个UI可以直接对数据进行查询。结合Grafana可以灵活构建精美细致的监控趋势图。

6、强大的聚合语法

内置查询语言，可以通过PromQL的函数实现对数据的查询、聚合。同时基于PromQL可以快速定制告警规则。

三、实践

1、监控的目的

在做监控系统之前，首先我们要明确监控的目的。在总结相关内容的时候，正好在网上看到了CNCF基金会Certified Kubernetes Administrator 郑云龙先生基于《SRE: Google运维解密》对监控目的的总结，总结很到位，所以就直接引用过来了。

引用来源：https://www.bookstack.cn/read/prometheus-book/AUTHOR.md

1）长期趋势分析：通过对监控样本数据的持续收集和统计，对监控指标进行长期趋势分析。例如，通过对磁盘空间增长率的判断，我们可以提前预测在未来什么时间节点上需要对资源进行扩容。

2）告警：当系统出现或者即将出现故障时，监控系统需要迅速反应并通知管理员，从而能够对问题进行快速的处理或者提前预防问题的发生，避免出现对业务的影响。

3）故障分析与定位：当问题发生后，需要对问题进行调查和处理。通过对不同监控监控以及历史数据的分析，能够找到并解决根源问题。

4）数据可视化：通过可视化仪表盘能够直接获取系统的运行状态、资源使用情况、以及服务运行状态等直观的信息。

一个监控系统满足了以上的这些点，涉及采集、分析、告警、图形展示，完善覆盖了监控系统应该具备的功能。下面就将近我们是如何基于Prometheus来打造数据库监控系统的。

2、我们的监控系统架构简介

其实我们在16年底开始使用到现在，中间也经历过几次架构演进。但是考虑到阅读体验，被替代的方案就不在这细说了，我们着重讲一下目前的架构设计和使用情况。首先看一下总体的架构。

我们逐个介绍一下上面架构图中的内容。

1）Agent

这是我们用golang开发的监控信息采集agent，负责采集监控指标和实例日志。监控指标包括了该宿主机的相关信息(实例、容器)。因为我们是容器化部署，单机实例数量大概在4-20左右。随着运维平台的实例增删，该宿主机上的实例信息可能会发生变化。所以我们需要agent能够感知到这个变化，从而决定采集哪些信息。另外采集间隔时间做到了10s，监控颗粒度可以做的更细，防止遗漏掉突发性的监控指标抖动。

2）Pushgateway

这是我们用的官方提供的组件，因为Prometheus是通过pull的方式获取数据的，如果让Prometheus Server去每个节点拉数据，那么监控服务的压力就会很大，我们是在监控几千个实例的情况下做到10s的采集间隔(当然采用联邦集群的模式也可以，但是这样就要需要部署Prometheus Server。再加上告警相关的东西以后，整个架构会变的比较复杂。)。所以agent采取数据推送至pushgateway，然后由Prometheus Server去pushgateway上面pull数据。这样在Prometheus Server在写入性能满足的情况下，单台机器就可以承载整个系统的监控数据。考虑到跨机房采集监控数据的问题，我们可以在每个机房都部署pushgateway节点，同时还能缓解单个pushgateway的压力。

3）Prometheus Server

Prometheus Server去pushgateway上面拉数据的时间间隔设置为10s。多个pushgateway的情况下，就配置多个组即可。为了确保Prometheus Server的高可用，可以再加一个Prometheus Server放到异地容灾机房，配置和前面的Prometheus Server一样。如果监控需要保留时间长的话，也可以配置一个采集间隔时间较大的Prometheus Server，比如5分钟一次，数据保留1年。

4）Alertmanager

使用Alertmanager前，需要先在Prometheus Server上面定义好告警规则。我们的监控系统因为是给DBA用，所以告警指标类型可以统一管理。但是也会有不同集群或者实例定义的告警阈值是不同的，这里怎么实现灵活配置，我后面再讲。为了解决Alertmanager单点的问题(高可用见下图)，我们可以配置成3个点，Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。确保及时在多个Alertmanager分别接收到相同告警信息的情况下，也只有一个告警通知被发送给Receiver。Alertmanager支持多个类型的配置。自定义模板，比如发送HTML的邮件；告警路由，根据标签匹配确定如何处理告警；接收人，支持邮件、微信、webhook多种类型告警；inhibit_rules，通过合理配置，可以减少垃圾告警的产生(比如机器宕机，该机器上面所有实例的告警信息就可以忽略掉，防止告警风暴)。我们告警是通过webhook的方式，将触发的告警推送至指定API，然后通过这个接口的服务进行二次加工。

▲ Prometheus和Alertmanager的高可用

5）filter&rewrite模块

这个模块的功能就是实现MySQL集群告警规则过滤功能和告警内容改写。

先说一下告警规则过滤，因为上面提到是统一设置了告警规则，那么如果有DBA需要对个别集群的告警阈值调整的话就会很麻烦，为了解决这个问题，我们在Alertmanager后面做了filter模块，这个模块接收到告警内容后，会判断这条告警信息是否超过DBA针对集群或者实例(实例优先级高于集群)设置阈值范围，如果超过就触发发送动作。告警发送按照等级不同，发送方式不同。比如我们定义了三个等级，P0、P1、P2，依次由高到低。P0，任何时间都会触发，并且同时触发电话和微信告警；P1，8:00-23:00只发微信告警，其他时间触发连续三次才触发发送；P2，8:00-23:00发送微信告警，其他时间发送不发送。

下图是集群和实例的告警阈值管理页面（这是集成在数据库运维平台内部的一个功能），针对每个集群和实例可以独立管理，新建集群的时候会根据所选CPU内存配置，默认给出一组与配置对应的告警阈值。

▲ 集群告警规则管理入口

▲ 实例告警规则管理入口

▲ 告警规则管理

接着看一下告警内容rewrite，比如上图看到的额外接收人，除了DBA有些开发同学也想接收告警，但是如果给他们发一个Thread_running大于多少的告警，他们可能不明白是什么意思，或者什么情况下会出现这个告警，需要关注什么。所有我们需要做一下告警内容的重写，让开发也能看的明白。下图就是我们改写过后的内容。

▲ 告警内容rewrite

还有告警关联，比如某个宿主机的磁盘IO高了，但是可能需要定位是哪个实例导致的，那么我们就可以通过这个告警，然后去监控系统里面分析可能导致IO高的实例，并且管理报警。如图所示：

▲ IO告警关联实例信息

最后说下一告警收敛，比如宿主机机宕机，那么这个宿主机上面的MySQL实例都会触发宕机告警(MySQL实例连续三个指标上报周期没有数据，则判定会为实例异常)，大量的告警会淹没掉重要告警，所以需要做一下告警收敛。我们是这样做的，宕机后由宿主机的告警信息来带出实例的相关信息，一条告警就能看到所有信息，这样就能通过一条告警信息的内容，得知哪些集群的实例受影响。如图所示：

▲ 宿主机宕机关联实例

6）Graph(画图)

Prometheus完美支持Grafana，我们可以通过PromQL语法结合Grafana，快速实现监控图的展示。为了和运维平台关联，通过url传参的方式，实现了运维平台直接打开指定集群和指定实例的监控图。

▲ 实例监控图

▲ 集群监控图

7）V-DBA

这是一个DBA的自动化程序，可以依赖告警信息实现一些指定操作，这里举一个过载保护的例子，我们的过载保护不是一直开启的，只有当触发了thread_running告警以后才会关联过载保护的动作。具体方案见下图：

8）告警管理

在运维平台上，我们有专门的页面用于管理告警，在手机端也做了适配，方便DBA随时都能连接到平台查看处理告警。从下图中可以看到当前触发的告警列表，无颜色标注的标识该告警已经被回复（属于维护性告警，回复以后不发送)，有颜色的这个代表未被回复告警(图中的这个属于P2等级告警）。另外可以注意到，这里的告警内容因为是给DBA看，所以没有做改写。

▲ PC端

▲ 手机端

基于告警日志，我们结合ES和Kibana实现了告警数据分析的功能，这种交互式的数据分析展示，能够帮助DBA轻松完成大规模数据库运维下的日常巡检，快速定位有问题的集群并及时优化。

▲ 告警分析

3、基于Prometheus的其他实践

基于Prometheus的方案，我们还做了其他监控告警相关功能扩展。

1）集群评分

由于我们做了告警分级，大部分的告警都是P2等级，也就是白天发送。以此来降低夜间的告警数量，但是这样一来可能会错过一些告警，导致问题不能及时暴露，所以就做了集群评分的功能来分析集群健康状况。并且针对一个月的评分做了趋势展示，方便DBA能够快速判断该集群是否需要优化。如下图所示：

▲ 集群评分

点击详情，可以进入该集群的详情页面。可以查看CPU、内存、磁盘的使用情况(这里磁盘空间达到了262%，意思是超过配额了)。另外还有QPS、TPS、Thread_running昨日和7日前的同比曲线，用来观察集群请求量的变化情况。最下面的注意事项还会标出扣分项是哪几个，分别是哪些实例。

▲ 详情页

2）指标预测

针对磁盘空间做了7日内小于200G的预测，因为多实例部署，所以需要针对当前宿主机上的实例进行当前数据大小、日志大小、日增长趋势的计算。DBA可以快速定位需要迁移扩容的节点实例。实现方法就是用了Prometheus的predict_linear来实现的(具体用法可以参照官方文档)。

▲ 磁盘空间预警

4、日志相关

1）SlowLog

SlowLog管理，我们是通过一套系统来进行收集、分析的，因为要拿到原生日志，所以就没有采用pt-query-digest的方式。架构如下：

通过agent收集，然后将原始的日志格式化以后以LPUSH方式写入redis(由于数据量并不大，所以就没有用Kafka或者MQ)，然后再由slow_log_reader这个程序通过BLPOP的方式读出，并且处理以后写入ES。这个步骤主要是实现了SQL指纹提取、分片库库名重写为逻辑库名的操作。

写入ES以后就可以用Kibana去查询数据。

对接到面向开发的数据库一站式平台，业务开发的同学可以查询自己有权限的数据库，同时我们也集成了小米开源的SOAR，可以用这个工具来查看SQL的优化建议。

通过ES进行聚合，可以给用户订阅慢查询的报表，有选择性的查看相关库的TOP慢SQL信息信息，有针对性的镜像优化。

2）Processlist，InnoDBStatus数据采集

为了能够在故障回溯或者故障时查看当时的会话快照和InnoDBStatus，我们在监控agent中内置了这个功能，也是每10秒一次，区别是会判断当前ThreadRunning是否到达阈值，如果到达才会采集数据，否则不采集。这样的设定既解决了无用日志太多的问题，又解决了性能异常时能够获取到状态信息。下图是日志采集处理的逻辑，其中日志处理模块是和慢查询处理在一个程序中，会话快照的处理逻辑和慢查询类似，这里就不赘述了。

四、总结

监控系统没有绝对的谁好谁不好，最重要的是适合自己的团队，能够合理利用最小的成本解决问题。我们从16年开始使用1.x版本到线下的2.x版本，目前基于Prometheus的监控系统，承载了整个平台所有实例、宿主机、容器的监控。采集周期10S，Prometheus一分钟内每秒平均摄取样本数9-10W。1台物理机(不包括高可用容灾资源)就可以承载当前的流量，并且还有很大的容量空间(CPU\Memory\Disk)。如果未来单机无法支撑的情况下，可以扩容成联邦集群模式。

另外本文中提到的监控系统只是我们运维平台中的一个模块，并不是一个独立的系统，从我们实践经验来看，最好是可以集成到运维平台中去，实现技术栈收敛和系统产品化、平台化，降低使用的复杂的。

最后说说在监控方面我们未来想做的事情，目前我们监控数据有了，但是告警只是发送了指标的内容，具体的根因还需要DBA分析监控信息。我们计划在第一阶段实现告警指标相关性分析后，可以给出一个综合多个监控指标得出的结论，帮助DBA快速定位问题；第二阶段能够更加分析结果给出处理建议。最终依赖整个监控体系，降低运维的复杂度，打通运维与业务开发直接的沟通壁垒，提升运维效率和服务质量。

作者介绍：

闫晓宇，同程艺龙数据库技术专家，具有多年互联网行业DB运维经验，在游戏、O2O及电商行业从事过DBA运维工作。2016年加入同程艺龙，目前在团队负责数据库架构设计及优化、运维自动化、MySQL监控体系建设、DB私有云平台设计及开发工作。

原文链接：

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650782138&idx=1&sn=7f4e6fba5910f6cd28d40498d9ed79a9&chksm=f3f90c2fc48e8539dc2121451fd9417d1afdfa41519ff70810083909d6cf41e9a47266149b48&scene=27#wechat_redirect

创作场景

从 Zabbix 到 Prometheus，同程艺龙数据库监控系统的实践