基于Prometheus的数据库监控

作者  金  戈

沃趣科技技术专家

传统监控系统面临的问题

传统监控系统，会面临哪些问题？ 
以zabbix为例 
 

初次使用需要大量配置，随着服务器和业务的增长会发现zabbix等传统监控面临很多问题：

1. DB性能瓶颈，由于zabbix会将采集到的性能指标都存储到数据库中，当服务器数量和业务增长快速扩张时数据库性能首先成为瓶颈。

2. 多套部署，管理成本高，当数据库性能成为瓶颈时首先想到的办法可能时分多套zabbix部署，但是又会带来管理很维护成本很高的问题。

3. 易用性差，zabbix的配置和管理非常复杂，很难精通。

4. 邮件风暴，邮件配置各种规则相当复杂，一不小心可能就容易造成邮件风暴的问题。

随着容器技术的发展，传统监控系统面临更多问题

1. 容器如何监控?

2. 微服务如何监控?

3. 集群性能如何进行分析计算?

4. 如何管理agent端大量配置脚本?

我们可以看到传统监控系统无法满足，当前IT环境下的监控需求

Prometheus的前身：Borgmon

2015年Google发表了一篇论文《Google使用Borg进行大规模集群的管理》 

这篇论文也描述了Google集群的规模和面临的挑战

1. 单集群上万服务器

2. 几千个不同的应用

3. 几十万个以上的jobs，而且动态增加或者减少

4. 每个数据中心数百个集群

基于这样一个规模，Google的监控系统也面临巨大挑战，而Borg中的Borgmon监控系统就是为了应对这些挑战而生。

Borgmon介绍

那么我们来看一下Google如何做大规模集群的监控系统

应用埋点

首先，Borg集群中运行的所有应用都需要暴露出特定的URL，http://<app>:80/varz 通过这个URL我们就可以获取到应用所暴露的全部监控指标。

服务发现

然而这样的应用有数千万个，而且可能会动态增加或者减少，Borgmon中如何发现这些应用呢？Borg中的应用启动时会自动注册到Borg内部的域名服务器BNS中，Borgmon通过读取BNS中应用列表信息，收集到应用列表，从而发现有哪些应用服务需要监控。当获取到应用列表后，就会将应用的全部监控变量值拉取到Borgmon系统中。 

指标采集与堆叠

当监控指标收集到Borgmon中，就可以进行展现或者提供给告警使用，另外由于一个集群实在是太过庞大了，一个Borgmon可能无法满足整个集群的监控采集和展现需求，所以一个数据中心可能部署多个Borgmon，分为数据收集层和汇总层，数据收集层会有多个Borgmon专门用来到应用中收集数据，汇总层Borgmon则从数据收集层Borgmon中获取数据。 

指标数据存储

Borgmon收集到了性能指标数据后，会把所有的数据存储在内存数据库里，定时checkpoint到磁盘上，并且会周期性的打包到外部的系统TSDB。通常情况下，数据中心和全局Borgmon中一般至少会存放12小时左右的数据量，以便渲染图表使用。每个数据点大概占用24字节的内存，所以存放100万个time-series，每个time-series每分钟一个数据点，同时保存12小时数据，仅需17GB内存。 

指标

指标的查询

Borgmon中通过标签的方式查询指标，基于标签过滤我们可以查询到某个应用的具体指标，也可以查询更高维度的信息 
基于标签过滤信息，比如我们基于一组过滤信息查询到host0:80这个app的http_requests指标 
 
我们也可以查询到整个美国西部，job为webserver的http_requests指标 
 
那么这个时候拿到的就是所有符合条件的实例的http_requests指标

规则计算

在数据收集和存储的基础之上，我们可以通过规则计算得到进一步的数据。 
比如，我们想在web server报错超过一定比例的时候报警，或者说在非200返回码，占总请求的比例超过某个值的时候报警。 

Prometheus

介绍

Borgmon是Google内部的系统，那么在Google之外如何使用它呢？这里就提到我们所描述的Prometheus这套监控系统。Google内部SRE工程师的著作《Google SRE》这本书中，直接就提到了Prometheus相当于就是开源版本的Borgmon。目前Prometheus在开源社区也是相当火爆，由Google发起Linux基金会旗下的原生云基金会（CNCF）就将Prometheus纳入其下第二大开源项目（第一项目为Kubernetes，为Borg的开源版本）。

架构

Prometheus整体架构和Borgmon类似，组件如下，有些组件是可选的：

• Prometheus主服务器，用来收集和存储时间序列数据

• 应用程序client代码库

• 短时jobs的push gateway

• 特殊用途的exporter（包括HAProxy、StatsD、Ganglia等）

• 用于报警的alertmanager

• 命令行工具查询

• 另外Grafana是作为Prometheus Dashboard展现的绝佳工具

数据库监控

基于Prometheus的数据库指标采集，我们以MySQL为例，由于MySQL没有暴露采集性能指标的接口，我们可以单独启动一个mysql_exporter，通过mysql_exporter到MySQL数据库上抓去性能指标，并暴露出性能采集接口提供给Prometheus，另外我们可以启动node_exporter用于抓取主机的性能指标。 

部署服务端

对于服务端配置非常简单，由于Prometheus全部基于Go语言开发，而Go语言程序在安装方面非常方便，安装服务端程序只需要下载，解压并运行即可。可以看到服务端常用程序也比较少，只需要包含prometheus这个主服务程序和alertmanager这个告警系统程序。 
 
服务端配置也非常简单，常用配置包含拉取时间和具体采集方式，就我们监控mysql数据库来讲，只需要填入mysql_exporter地址即可。 

部署exporter端

对于mysql采集只需要配置连接信息，并启动mysql_exporter即可 

完成配置之后即可通过mysql_exporter采集mysql性能指标 
 
然后我们在prometheus服务端也可以查询到采集的mysql性能指标 

基于这些采集指标和Prometheus提供的规则计算语句，我们可以实现一些高纬度的查询需求，比如用这个语句，increase(mysql_global_status_bytes_received{instance="$host"}[1h]) 
我们可以查询MySQL每小时接受到的字节数，然后我们将这个查询放到Grafana中，就可以展现出非常酷炫的性能图表。

而目前结合Prometheus和Grafana的MySQL监控方案已经有开源实现，我们很轻松可以搭建一套基于Prometheus的监控系统 
 
对于告警方面我们也可以基于Prometheus丰富的查询语句实现复杂告警逻辑 
比如我们要对MySQL备库进行监控，如果复制IO线程未运行或者复制SQL线程未运行并且持续2分钟就发送告警我们可以使用如下这条告警规则。

1. # Alert: The replication IO or SQL threads are stopped.

2. ALERT MySQLReplicationNotRunning

3.  IF mysql_slave_status_slave_io_running == 0 OR mysql_slave_status_slave_sql_running == 0

4.  FOR 2m

5.  LABELS {

6.    severity = "critical"

7.  }

8.  ANNOTATIONS {

9.    summary = "Slave replication is not running",

10.    description = "Slave replication (IO or SQL) has been down for more than 2 minutes.",

11.  }

在比如，我们要监控MySQL备库延迟大于30秒并且预测在未来2分钟之后大于0秒持续1分钟，则告警

1. # Alert: The replicaiton lag is non-zero and it predicted to not recover within

2. #        2 minutes.  This allows for a small amount of replication lag.

3. ALERT MySQLReplicationLag

4.  IF

5.      (mysql_slave_lag_seconds > 30)

6.    AND on (instance)

7.      (predict_linear(mysql_slave_lag_seconds[5m], 60*2) > 0)

8.  FOR 1m

9.  LABELS {

10.    severity = "critical"

11.  }

12.  ANNOTATIONS {

13.    summary = "MySQL slave replication is lagging",

14.    description = "The mysql slave replication has fallen behind and is not recovering",

15.  }

当然在数据库方面不只是有MySQL的监控实现，目前业界也有很多其他开源实现，所以在数据库监控方面也能实现开箱即用的效果

• mysql_exporter 

https://github.com/prometheus/mysqld_exporter

• redis_exporter 

https://github.com/oliver006/redis_exporter

• postgres_exporter 

https://github.com/wrouesnel/postgres_exporter

• mongodb_exporter 

https://github.com/percona/mongodb_exporter

近期文章回顾：

关于沃趣

杭州沃趣科技股份有限公司创建于2012年（股票代码：839849），创始团队为原阿里巴巴数据库及系统运维团队核心骨干，凭借着多年的运维经验，为行业客户提供专业数据库、系统相关的服务和产品；专注为用户提供基于高性能、高可用、可扩展的开放数据库云平台解决方案的国产厂商。

沃趣科技的产品已广泛应用于证券、保险、医疗、广电传媒、银行、电信、能源电力、快递物流、公共事业、大型企业等，为这些行业用户持续提供行业解决方案及服务支持。

研发中心位于杭州，同时在北京、上海、广州、南京、兰州建立了分支机构,拥有辐射全国的销售和服务体系。

我们始终坚信，数据是驱动企业创新的源动力！坚持围绕企业数据库做好一件事

                        ——让高性能触手可及！