PMM监控系统的使用思考

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

参考阅读：

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