一、项目背景

2019年10月底，本人入职了点我达， 点我达是一家“众包模式的即时物流平台”，致力于末端即时物流服务，以众包共享模式，为用户提供直接从门到门的快速、准时、可信赖的物品送达服务。https://www.dianwoda.com/

目前点我达的数据库集群主要集中在3个区域， 一个是杭州阿里云的rds集群，  一个是上海阿里云idc自建的数据库集群， 还有一个是杭州idc自建数据库集群，总的数据库实例规模大概在500左右， 阿里云rds的监控展示和报警推送，完全依赖于阿里云的云监控。

需要解决的问题

当然，不是说阿里云的云监控不好， 是当集群规模达到一定数量之后

1、实例纵向维度的对比很难做， 无法做时间跨度比较大的监控趋势查看

2、实例横向的对比很难去做，比如订单分片后，各个分片节点rds的负载、请求等情况，无法做横向对比

3、监控指标较单一， 无法新增新的监控指标

4、报警规则比较单一，无法做定制化的报警规则和推送

5、引擎层的监控数据采集频率无法控制，且如果小于60s需要额外付费用

所以基于以上几点原因， 本人做了rds数据库监控的本地化改造， 即将rds的引擎监控、机器层面监控、以及报警推送等转为dba自己来做， 脱离阿里云云监控， 同时监控系统同样适用于idc自建数据库，达到监控体系的统一。

二、项目架构

思考：

本地化监控改造大概分为以下几个部分：

1、定监控体系架构， 决定采用当前比较流行并且本人比较熟悉的prometheus监控体系

2、1对多问题，常规的自建数据库监控一般使用prometheus的官方mysqld_exporter,在ecs上部署一个exporter，1对1进行监控。但是rds没有实体机器来部署exporter 所以需要对官方的mysqld_exporter 进行改造或者重新开发，让exporter支持1对多的监控。这里我是采用比较快的方法，直接拿官方mysqld_exporter 进行源码修改。

3、机器层面的监控，node_exporter 跟mysqld_exporter 一样， 直接拿官方源码进行修改，支持1对多的监控

4、rds实例过多， 如果一一把配置都写进prometheus比较繁琐，故这里使用prometheus 里的consul config特性，将数据库实例信息注册到consul，然后prometheus 从consul里抓取实例信息，下发给exporter， exporter 再去具体实例上抓取需要的监控信息。

5、报警收敛和分级推送。点我达已经有了一套报警收敛、推送的自研系统， 所以这里只需把报警推送到Alertmanager 就可以了。

6、监控图表展示， 毫无疑问使用grafana。grafana里有一个percona的插件，可以直接生成各种监控图表，且能与mysqld_exporter 和node_exporter无缝对接(rds这里不一样，需要自己画图)。

具体架构：

解决了以上6个问题，那么就有了下面的监控体系架构。

三、相关服务模块

1、consul注册服务

点我达目前的ops运维管理平台是比较open的，每个人都可以自己开发服务， 开放http接口，然后就可以接入ops平台了。  因为数据库实例的特殊性，一般都是在新建或者删除的时候，才把注册信息更新， 所以这里，我直接用go开发了一个consul注册的服务， 接入了ops管理平台，同时又有了流程审批控制， 一举两得。

目前注册和注销均在点我达ops运维平台里做， 具体流程如下：

注册完成后，consul上显示的信息如下：

具体注册接口与注册操作方法，详细请参考本人的开源项目：iushas/consul_register

github地址为：https://github.com/iushas/consul_register

2、promehteus里的配置

promehteus里的配置最为关键，因为同时涉及到mysqld_exporter 和 node_exporter ，所以这里同时把两个配置同时贴出来，供大家参考。

1）mysqld_exporter的配置：

同时支持不接入consul，1对1监控和接入consul，实例id下发，1对多监控。

2）node_exporter的配置：

配置里的tag是第一步consul注册的时候注册进去的数据库属性， 可以为 hz-ali 代表杭州的rds， 可以为 sh-idc 代表上海的自建机房。所以第一步注册信息很重要，后面不同的prometheus里的region和其他属性的区分，都是通过consul里打的tag来实现的。

3、mysqld_exporter

定制化exporter 支持一对多， 由于consul里没有注册每台rds实例的监控账号，所以要求每台实例的监控账号和密码权限统一。

这里只解释下如何实现以对多的监控。

这里配置很简单，只要在.my.cnf里把账号密码配置进去就可以了， host可以随便写。

配置好后， 把服务拉起来， Prometheus里的 这一段配置会把向exporter-address:9104 这个请求地址发送的scrape请求，添加上一个参数，

target=__address__, 这个__address__是从consul里读取到的rds的 tcp的地址

比如我的这个地址：

下发的给exporter的请求为：

然后exporter拿到这个地址请求后，把需要的实例信息解析出来，通过地址去数据库里拿去监控信息， 这样每次protheus下发新的地址后，exporter会拿新的地址去查询，就实现了一个exporter监控多个数据库的功能。

详细的mysqld_exporter的代码介绍和实现参见本人的开源项目：

github地址为：https://github.com/iushas/mysqld_exporter

4、node_exporter

node_exporter 跟mysqld_exporter 差不多，也是基于Prometheus官方提供的监控插件来修改，但是这里跟mysqld_exporter 不同的是，

1、阿里云rds机器层面的监控，只能通过阿里云aliyun的监控和属性API进行获取，使用阿里云aliyun的 API，又涉及到角色授权等。

2、对于真实的虚拟机监控，还是只能做1对1的监控，即一个node_exporter 对应一个ecs机器。

3、调用阿里云API的监控，可以实现1对多。

所以这里可以看到第二步Prometheus里的配置一部分还是原来的node配置，一部分是新增加的监控参数配置（带Rds的）

详细介绍参见本人的开源项目：

github地址为：https://github.com/iushas/node_exporter

5、报警推送

这里不再简述了， 就是在prometheus里设置阈值， 然后推送给Alertmanager，  然后Alertmanager后面还有一套报警推送和收敛的系统，详情请看上面的整体监控架构图。

四、图表展示

这里图表展示分为2部分，一部分是引擎层面的监控图，直接使用的是Grafana里的Percona插件。另一部分机器层面的监控需要自己手动画图。

关于这部分，我不打算详细说明，只给大家贴两张图好了。

五、总结

目前市面上还没有将数据库的监控exporter做成1对多的方案， 我的这次修改首次实现了这个功能，结合Prometheus，减少了运维成本。经过这次改造， 点我达的rds监控和本地自建数据库的监控有了一个完整统一的监控体系， 目前仍在持续接入中。我后面会持续更新迭代，解决和优化数据库性能、监控、高可用等方面的问题，并且输出一些其他的高质量实战工具和文章。同时本文章的几个服务已经开源，也希望能给提供给开发能力没有很突出的dba们，感兴趣的同学可以尝试一下。