很早就听说过PMM，Percona开发的一套对MongoDB, MySQL, Postgres建立监控系统的套件。曾经也抽空想试用下，但由于使用上的各种毛病，以及文档欠缺，没成过。最近在Mongo中文社区里听群友谈到已经有PMM2了，迫不及待地搭建一把，看看什么样子，毕竟网络上详细谈PMM搭建的貌似不多，此文抛砖引玉。
PMM是什么呢？简单说这是Percona开发的用来监控mysql,postgres，mongodb的一揽子方案，即它把该用的组件全部包在一起了，只向外暴露一个pmm-client,一个pmm-server；里面囊括了cloud-native氛围下大为流行的prometheus, grafana监控工具。
其pmm-client主要包括各种exporters（exporter是prometheus中的概念，是一种将服务metrics抓取的第三方工具，供prometheus来scrape），如node_exporter抓取主机metrics信息， mongodb_exporter抓取mongod, mongos metrics信息。
pmm-server内将prometheus,grafana,consul等工具一起打包，以整体方式提供服务；其中prometheus是时序数据库，grafana是监控面板系统，其可配置prometheus为它的一个数据源， consul作为服务发现组件，便于屏蔽后端的节点变更。
很多文档说用yum安装，但我没成过，估计是添加yum源的问题。干脆直接rpm安装，下载地址：
v2版本，而不是v1，貌似很不兼容，曾经搭v1没搭成
此次为方便起见，采用了多数文章建议的方式，docker 容器运行，步骤：
dockercreate -v /srv –name pmm-data percona/pmm-server:2 /bin/true
dockerrun -d -p 8080:80 -p 443:443 –volumes-from pmm-data –name pmm-server–restart always percona/pmm-server:2
如果主机不允许docker运行，恐怕得需自行编译了。官方文档似乎并未说清楚该如何自行编译打包安装，有朋友探索过不妨分享下。
这里注册节点的意思就是指把各个mongos,mongod节点加入到监控中。这是通过pmm-client来做的。
首先，pmm-client要感知到pmm-server:
# pmm-admin config –server-insecure-tls–server-url=https://admin:admin@<ip>
– admin,admin是默认的用户、密码，<ip> 是pmm-server 的ip地址
此命令的输出其实是每台 pmm-client机器上启动了 pmm-agent进程，用以采集各service的数据
# pmm-admin add mongodb –cluster”cluster1″ –replication-set “cluster1_0” –username xxx–password xxx <ip>:<port> <ip>:<port>
命令格式我们可以随时用pmm-admin addmongodb -h 来查看。有些选项含义是显而易见的，可以知道第一个ip:port指 service name， 第二个是service address。我习惯让service name取值为service address，好处是在grafana的 Service Name下拉框里会显示 ip:port，这样我们更易区分同一机器上的不同节点（默认时取为主机名，非常不适合标识同一机器上的不同节点！）。如下图所示：
中说的先创建 mongodb_exporter，分配clusterMonitor权限来做，直接用一个有足够权限的用户也可以；当然单独分配一个用户应该更安全；
如果是添加mongos节点，和mongod差不多，不过需移除 –replica-set 选项
将mongod, mongos加入后，我们可通过 pmm-admin list发现，服务节点已经注册了：
如果进入到pmm-server容器中去看，会发现，在/etc/prometheus.yml中已经加入了多个targets，
然后去<host>/prometheus/targets，我们会发现，所有的targets都UP状态，如果有不是UP状态的，看看是否是网络故障或配置问题：
下面以我的本地一主二从的副本集集群 1p2s 举例，YCSB以insert ops=100 load
集群指标
实例指标
可见指标是多么地集中、丰富！对于分析定位问题，抓住因果关系，是非常有利的。
相信看到这里，大家能明白，PMM其实是一套可以快速建立mongo监控系统的工具，非常适合于迭代开发、测试过程。当然由于其各个组件被bundle在一起，可能存在以下的缺陷：
1. 无法灵活扩展，节点多了后，一个pmm server能撑住吗？
2. 如果是云服务，可能需要重新考虑架构，负载均衡，自动化配置等
3. 不容易定制。pmm-client, pmm-server是不是暴露了足够多的功能供调用呢？特别是如果我们想定制grafana 的template 变量，label不满足需求怎么办？
4. 面板中的metrics计算是否都准确？很多指标需要熟悉
当然我们也可以选择单独部署各个组件，毕竟PMM证明了可行性。比如我们考虑把无状态的服务如exporter, grafana 放到k8s集群里，其管理由k8s负责；甚至prometheus带有 data目录的组件也可放进去，毕竟是时序数据库，可以允许一定时间的rotation。这样好处就是灵活，管理也不复杂，交给k8s，但配置会略微麻烦，得很懂 prometheus.yml的语法。最终可怎么用，看我们的需求了。
一名热衷和专职于数据库、分布式、存储技术的技术人，对linux内核、微处理器架构也颇有兴趣。工作初接触redis/couchbase/scylladb等NoSQL数据库，现在腾讯做mongo云数据库开发。业余时间喜欢爬山，研究论文，学习人文。
References
MongoDB中文社区
评论前必须登录！
注册