PMM监控系统的使用思考

Posted 2021-01-19

PMM监控系统的使用思考

[TOC]

为什么需要监控

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的架构

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

配置好之后，就会生成上图中IP和PORT两个标签

然后对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目前还是个没有对手的开源监控系统