PMM监控系统的使用思考

为什么需要监控

  1. 查看数据库的趋势,观测当前QPS/TPS等信息,这是最基本的了。开发或者领导问现在实例情况如何的时候,你还吭哧吭哧的登录跳板机,运行脚本打印实例情况,一套操作下来半分钟没了,已经错过现场
  2. 忽悠开发,开发问为啥这么卡,看下监控,数值都正常—>你们的应用有问题。数值不正常—>我们已经注意到了问题,正在排查。
  3. 未雨绸缪,为扩容,提升机器效能(指收缩机器占用,下线不用的实例)提供参考。负载比较高的要考虑扩容,性能差的要考虑优化。负载低的基本没有连接的考虑要申请下线,

为什么是PMM

这里贴一个官方示例网址

  1. 监控信息最全,开源的监控方案我用过zabbix,open-falcon,自己采集+ES+Kibana/grafana。采集的指标项很多是数据有误,不及时,或者根本无数据。这样的抽风的监控系统会给自己的分析带来不自信,有存在的必要吗?
  2. 界面最直观,细节较多。你能想到的,想不到的都给你提供了。这对我这样菜逼DBA来说是很重要的。可以根据监控图形趋势猜出实例crash或者高负载前后的信息。信息少的监控系统分析不出什么花样来,瞎抠浪费时间。
  3. 支持的数据库类型最多,PG/MySQL(含PXC,MGR,TOKU,ROCKS)/MongoDB(含MONGOS)/OS。分析一个业务的OS/MONGODB/MYSQL性能要跨越两三个web网站,烦不烦?
  4. 支持慢查询分析,比annometer或者logstash的配置比起来简单一万倍。只要配置监控就可以,agent可以根据可调节的开关从IS或者慢日志中捕捉慢查询,高频SQL
  5. 基于grafana,可以引入oauth或者Ldap方便对现有的组织结构进行引入,根据业务对于图形进行分别授权。防止业务的活跃信息,IP等有价值信息被泄露
  6. 集成了Orchestrator用于复制拓补管理和可视化(这个我也没用过)

PMM又有哪些缺点

PMM 默认使用主机名作为唯一识别数据库实例的关键字。

在docker环境下,单机单实例,实例名和主机名保持一致,比较方便,但是不对外展示IP和端口还是蹩脚。也有可能是我的视野比较窄,或许根本不需要。但是在我们这边没有数据库微服务的情况下,IP和端口还是比较关键的信息点,而且单物理机多数据库实例下的使用效果并不好。主要体现在无法使用IP对实例进行汇总

需要sudo权限

在某些权限管理比较严格的情况下,dba没有sudo权限,无法运行pmm-client

服务端不好拆分

官方采用单节点Prometheus来存储监控Metric,小环境还可以,数千数万台的情况下ova或者docker化的服务端容易爆盘。这个时候易于部署的ova或者docker分发方式反而变成了缺点。

ova分发方式修改ova密码麻烦

修改Ova的虚拟机的Linux密码后,访问监控页面也需要输入密码,agent端注册也需要密码。当然如果你不去修改Ova的密码也没问题

服务端load高

这里简单说下PMM的架构 PMM架构

  1. 客户端(agent)向consul的kv中注册自己监控的服务信息
  2. 存储端(prometheus)从consul提供的服务发现服务地址去分别获取agent注册的信息,然后去一个个抽取exporter产生的监控数据
  3. Grafana通过读取存储端存储的数据进行展示
  4. 图中的地址不是直接对外暴露的,有一层nginx转发
  5. QAN的查询语句分析功能是通过另外的QAN服务单独进行分析并推入prometheus的
  6. 有一个MySQL实例用于存储整套系统的元数据信息。
  7. 还有一个大多数人不会投入使用的Orchestrator

这里显然可以得出,在监控数据量增大,监控节点增多的情况下,整个docker或者ova都会被qan的分析和prometheus的读写拖慢

解决思路

使用relabel功能分离IP和端口信息,修改grafana页面

这里主要是使用了prometheus配置文件中的relabel功能将__meta_consul_tags重新打标签为IP和PORT。

  # 截取IP和PORT zrz 20181112
  - source_labels: [__meta_consul_tags]
    separator: ;
    regex: .*,alias_([-\w:\.]+):.*
    target_label: IP
    replacement: $1
    action: replace
  - source_labels: [__meta_consul_tags]
    separator: ;
    regex: .*:([-\w:\.]+),.*
    target_label: PORT
    replacement: $1
    action: replace

为了找到这个功能,我花费了很长时间,需要使用正则的分段匹配和替换的方式进行截取。\

突破点在于Prometheus的管理web上,这里贴出来,相信大家会马上明白

只要在添加数据实例监控时指定ip加端口,当然最好自定义生成下客户端的pmm.yml配置文件

vim /usr/local/percona/pmm-client/pmm.yml

server_address: 250.250.250.250 # 服务端的地址,若变更了端口,请加上端口
client_address: 1.1.1.1         # 本机IP
bind_address: 1.1.1.1           # 本机IP
client_name: 1.1.1.1            # 这里通常会是主机名,但是建议改成IP,方便生成IP端口

# agent在本地添加数据库监控实例时:
pmm-admin add mysql --socket /home/dba/heart/break1/mysqld.sock --user flattery --password dog 1.1.1.1:4306
pmm-admin add mysql --socket /home/dba/heart/break2/mysqld.sock --user at --password last 1.1.1.1:5306
pmm-admin add mysql --socket /home/dba/heart/break2/mysqld.sock --user have --password nothing 1.1.1.1:6306

配置好之后,就会生成上图中IPPORT两个标签 \

然后对granfana的variable进行自定义

label_values(mysql_up,IP)

label_values(mysql_up,PORT)

在对图形的query进行修改,如图:

到这里,剩下的想必聪明的你就知道该怎么做剩下的了。

需要注意的是在cross页面,需要使用sum函数(可以省略by),可以对整个实例的QPS进行汇总求和。这里的sum函数可以对实例级别的QPS进行汇总,而不是对时段内单实例进行汇总

tags功能需要使用查询CMDB来实现,也就是根据业务对机器和实例进行汇总,然后查询业务名传给tags,然后查询IP端口给tags

拆分pmm-client
  • 需要sudo权限的原因是某些Os级别的监控需要权限,而且pmm-client使用了supervisord对监控进程进行了照顾。这两方面其实可以省略。那么就需要修改代码去掉这两个方面就可以了。

  • 官方使用了pmm-managed包对node_exporter,mysqld_exporter等的的添加进行了包装,其中比较重要的是,监控的部分元数据采集到MySQL(连接方式,监控类型等),接收连接方式的配置并喂食给exporter,调用consul包对监控服务的发现进行了add,update,delete,对应了pmm-admin的purge,uninstall,repair等等命令

  • 我不会go语言。

服务端拆分

可以从docker分发的/opt/entry.sh脚本入手,天不早了。这里留给聪明的你 自己探索

服务端拆分可以(也是必须)解决如下问题:

  • load高,把各个服务分到不同的机器上
  • 监控数据爆盘,利用Prometheus的federate功能,也就是垂直拆分的方式,拆分promethus。或者将Prometheus的存储换为可以分片的es,opentsdb等等

总结

  • 如若解决了Pmm-client的IP和端口采集问题,pmm-server的拆分的难度,我相信Pmm的易用性会大大提升

  • 虽然有上述问题,但pmm目前还是个没有对手的开源监控系统

参考阅读:

https://prometheus.io/docs/prometheus/latest/querying/basics/ https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cconsul_sd_config%3E https://www.ctolib.com/docs/sfile/prometheus-book/sd/service-discovery-with-relabel.html https://www.shellhacks.com/prometheus-delete-time-series-metrics/ http://dockone.io/article/3065