PMM监控系统的使用思考
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了PMM监控系统的使用思考相关的知识,希望对你有一定的参考价值。
PMM监控系统的使用思考
[TOC]
为什么需要监控
- 查看数据库的趋势,观测当前QPS/TPS等信息,这是最基本的了。开发或者领导问现在实例情况如何的时候,你还吭哧吭哧的登录跳板机,运行脚本打印实例情况,一套操作下来半分钟没了,已经错过现场
- 忽悠开发,开发问为啥这么卡,看下监控,数值都正常—>你们的应用有问题。数值不正常—>我们已经注意到了问题,正在排查。
- 未雨绸缪,为扩容,提升机器效能(指收缩机器占用,下线不用的实例)提供参考。负载比较高的要考虑扩容,性能差的要考虑优化。负载低的基本没有连接的考虑要申请下线,
为什么是PMM
这里贴一个官方示例网址
- 监控信息最全,开源的监控方案我用过zabbix,open-falcon,自己采集+ES+Kibana/grafana。采集的指标项很多是数据有误,不及时,或者根本无数据。这样的抽风的监控系统会给自己的分析带来不自信,有存在的必要吗?
- 界面最直观,细节较多。你能想到的,想不到的都给你提供了。这对我这样菜逼DBA来说是很重要的。可以根据监控图形趋势猜出实例crash或者高负载前后的信息。信息少的监控系统分析不出什么花样来,瞎抠浪费时间。
- 支持的数据库类型最多,PG/mysql(含PXC,MGR,TOKU,ROCKS)/MongoDB(含MONGOS)/OS。分析一个业务的OS/MONGODB/MYSQL性能要跨越两三个web网站,烦不烦?
- 支持慢查询分析,比annometer或者logstash的配置比起来简单一万倍。只要配置监控就可以,agent可以根据可调节的开关从IS或者慢日志中捕捉慢查询,高频SQL
- 基于grafana,可以引入oauth或者Ldap方便对现有的组织结构进行引入,根据业务对于图形进行分别授权。防止业务的活跃信息,IP等有价值信息被泄露
- 集成了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的架构
- 客户端(agent)向consul的kv中注册自己监控的服务信息
- 存储端(prometheus)从consul提供的服务发现服务地址去分别获取agent注册的信息,然后去一个个抽取exporter产生的监控数据
- Grafana通过读取存储端存储的数据进行展示
- 图中的地址不是直接对外暴露的,有一层nginx转发
- QAN的查询语句分析功能是通过另外的QAN服务单独进行分析并推入prometheus的
- 有一个MySQL实例用于存储整套系统的元数据信息。
- 还有一个大多数人不会投入使用的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目前还是个没有对手的开源监控系统
以上是关于PMM监控系统的使用思考的主要内容,如果未能解决你的问题,请参考以下文章