RDS数据库本地化监控改造

一、项目背景

目前点我达的数据库集群主要集中在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们,感兴趣的同学可以尝试一下。


更多详细内容,参考本人的相关文档:

点我达博客:rds数据库本地化改造

微信公众号:rds数据库本地化改造

你可能感兴趣的:(RDS数据库本地化监控改造)