使用PMM图形化监控MySQL MGR动态

1.引入

目前市面上对于MySQL相关的监控平台，监控软件，自动诊断平台，或者称之为云管平台等众多但是针对MGR高可用组复制和主从延迟，或者主从复制实时延迟的监控工具相对有限，缺乏直观的MySQL高可用架构的展示和复制延迟，分析，建议等可量化观测的指标，而且部分监控配置起来相对较为繁琐。

2.PMM监控的安装和配置使用

今天我们就来介绍一款开源的图形化监控平台PMM，其提供友好监控UI界面，支持MySQL多种存储引擎详细指标监控展示，以及多种类型数据库以及数据库中间件的运行监控。

2.1PMM介绍

PMM 全称percona-monitoring-and-management，以下简称PMM PMM是Percona Monitoring and Management监控并支持MySQL多个分支版本，包括Percona Server for MySQL、Percona XtraDB Cluster、Oracle MySQL Community Edition、Oracle MySQL Enterprise Edition和MariaDB。

PMM其结构是C/S结构，由客户端pmm-agent和服务器端pmm-server组成

pmm-client安装在被监控的主机上，pmm-server则可以独立安装在一台监控服务器上。用户通过Grafana来查看监控试图和动态，其后调用QAN查询分析器分析一段时间内的数据库查询性能，QAN App 是一个 Web 应用程序，用于可视化收集的查询分析数据，性能数据来源主要是通过QAN api接口调用pmm-client中的agent代理来采集的，VictoriaMetrics一个可扩展的时间序列数据库，记录事实变化，用户可通过不同时间段来进行范围查询调整（PMM 2.12.0中VictoriaMetrics替换了Prometheus），ClickHouse是第三方面向列的数据库，主要作用是用来提高查询分析效率。Postgresql数据库则记录了平台的配置和相关标签信息等。mointored database为被监控的数据库实例，exports为提供的监控组件类型，可监控不同的数据库对象，则按需调用不同的exporters接口

客户端和服务器端对应组件的分布和交互关系：pmm-agent是一个客户端组件 一个最小的命令行界面，它是负责引入客户端功能的中央入口点：它进行客户端的身份验证，获取存储在 PMM 服务器上的客户端配置，管理导出器和其他代理。为了确保从 PMM Client 到 PMM Server 的数据传输安全，所有导出器都可以使用 SSL/TLS 加密连接，并且它们与 PMM 服务器的通信受到 HTTP 基本身份验证的保护。

2.2PMM安装方式

如官方所描述支持3种部署方式

1、Docker方式安装。

优点是简单，快捷，方便，但前提条件是安装pmm-server的主机需要联接外网，装完Docker之后，可以直接拉取pmm-server镜像运行，pull镜像大概500M+，需要结合自己的网络状况。

2、使用VirtualBox虚拟机方式安装。

目前可以下载到对应pmm-server的OVF格式文件，此文件是由Oracle公司的VirtualBox虚拟机支持，可以将下载的PMM文件导入到VirtualBoxOVF虚拟机后再配置。缺点是OVF下载速度太慢了。

3、亚马逊AWS云环境。

可以在AWS Marketplace应用市场上找到对应的percona的PMM监控选装，安装相对简单，PMM监控免费，但对应pmm-server基础运行的linux云环境需要付费。

鉴于AWS环境目前没账号，VirtualBox虚拟对应pmm-server的OVF格式文件下载较为缓慢，下载时长超过12小时，所以本次先介绍docker安装方式。

2.2.1首先安装docker

当前系统版本：redhat 7.7版本
[root@master1 ~]# cat /etc/redhat-release
#Red Hat Enterprise Linux Server release 7.7 (Maipo)
You have mail in /var/spool/mail/root
[root@master1 ~]#

2.2.2配置yum工具

配置docker安装的yum源的地址，下列阿里云的和官方的二选一即可 阿里云地址：

yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

官方地址（官网地址我试了2次，每次都中断可能和网络环境有关）：

yum-config-manager --add-repo  https://download.docker.com/linux/centos/docker-ce.repo

安装docker所用到的系统包3个，yum配置单元，驱动映射包，和lvm逻辑卷管理命令

yum install -y yum-utils device-mapper-persistent-data lvm2

2.2.3执行docker安装

查看对应的yum仓库地址中所有的版本信息

yum list docker-ce --showduplicates | sort -r

如果在redhat7.7直接安装yum -y install docker-ce-17.03.2.ce-1.el7.centos.x86_64 可能会遇到报错如下：

Error: Package: containerd.io-1.6.4-3.1.el7.x86_64 (docker-ce-stable)
           Requires: container-selinux >= 2:2.74
错误提示缺少依赖container-selinux包等

安装指定低版本，并加上docker-ce-selinux-17.03.2.ce-1.el7.centos.noarch

yum install --setopt=obsoletes=0 docker-ce-17.03.2.ce-1.el7.centos.x86_64  docker-ce-selinux-17.03.2.ce-1.el7.centos.noarch

4、启动docker服务，并添加到系统自启动服务中

[root@master1 ~]# systemctl start docker
[root@master1 ~]# systemctl enable docker

2.2.4安装pmm-server服务器端

上边我们介绍过了PMM采用的是C/S结构，也就是客户端到服务器端的结构，所以分两部分，一部分是pmm-server，另一部分是pmm-client

1、首先在监控主机上安装pmm-server 直接在当前linux系统上拉取pmm-server镜像：

[root@master1 ~]# docker pull percona/pmm-server:latest
latest: Pulling from percona/pmm-server
2d473b07cdd5: Pull complete
27986f2f1173: Pull complete
Digest: sha256:60941a479dba0ab8c989af8bac37513518d615676a4c9782fd0331fd33143cf9
Status: Downloaded newer image for percona/pmm-server:latest

2、在pmm-server创建数据卷路径

docker create --volume /srv \
--name pmm-data \
percona/pmm-server:latest /bin/true

查看docker镜像信息
[root@master1 ~]# docker images
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
percona/pmm-server   latest              15bdcd948d1e        3 weeks ago         1.85 GB

3、然后运行pmm-server容器

启动pmm-server
docker run --detach --restart always \
--publish 443:443 \
--volumes-from pmm-data \
--name pmm-server \
percona/pmm-server:latest

4、这样pmm-server就安装完成了，可以通过docker命令查看运行情况

[root@master1 ~]# docker ps
CONTAINER ID        IMAGE                       COMMAND                CREATED             STATUS                  PORTS                          NAMES
a0dad7c3f137        percona/pmm-server:latest   "/opt/entrypoint.sh"   23 hours ago        Up 23 hours (healthy)   80/tcp, 0.0.0.0:443->443/tcp   pmm-server

5、接下就可通过浏览器登录pmm-server了 可以在windows浏览器中输入pmm-server的IP地址访问：https://172.16.130.12 （注意：https而非http）

默认初始登录的用户名密码为：admin/admin 另外注意浏览器的问题：浏览器部分版本可能不支持Grafana的UI界面，比如我用搜狗浏览器和360浏览器都出现了如下的提示：

支持的浏览器如：1、Chrome/Chromium 谷歌浏览器 2、Firefox 火狐浏览器 3、Safari MAC系统的Safari 4、Microsoft Edge 或 IE 11 以上。

如果想要预先修改Grafana登录密码可以使用如下命令：

docker exec -t pmm-server change-admin-password <new_password>

2.2.5安装pmm-client客户端

在每个要监控的MySQL服务器上下载安装PMM-CLIENT 安装方式有2种：

1、如果无外网连接环境，可以预先下载二进制包，然后手动scp分发到要监控的主机上手动安装。

2、如果可以连接网络，则可以通过yum方式在线安装。

两种方法如下：

• 第一种、二进制包安装 1、官网下载二进制包，然后scp拷贝到要监控的MySQL主机上，考虑到MySQL服务器端可能无法联网，所以可以采用下载二进制包安装的方法进行。‍

wget https://downloads.percona.com/downloads/pmm2/2.28.0/binary/tarball/pmm2-client-2.28.0.tar.gz

2、解压二进制包

tar xfz pmm2-client-2.28.0.tar.gz && cd pmm2-client-2.28.0 && ./install_tarball

3、配置环境变量，设置export PMM_DIR路径

vim ~root/.bash_profile
#如下：
export PMM_DIR=/usr/local/percona/pmm2
export PATH=$PATH:$PMM_DIR/bin
source  ~root/.bash_profile

4、配置pmm-client客户端

a)使用pmm-agent
pmm-agent 是一个客户端的组件，一个最小的命令行接口，它是使用客户端功能的中心入口点，包括客户权限认证、从PMM服务端获取存储的客户端配置、管理导出器和其他的代理
pmm-agent setup --config-file=/usr/local/percona/pmm2/config/pmm-agent.yaml --server-address=192.168.1.123 --server-insecure-tls --server-username=admin --server-password=admin
pmm-agent --config-file=/usr/local/percona/pmm2/config/pmm-agent.yaml

b)pmm-admin status
 pmm-admin 是一个管理PMM客户端的命令行工具，作用是添加或者移除需要被监控的数据库实例

• 第二种、yum在线安装 如果可以连接外网，则可以直接使用yum安装 首先，配置yum的repo仓库地址

yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm

其次，直接安装pmm-client客户端即可

yum install -y pmm2-client

然后，装完后检查下版本信息。

pmm-admin --version
pmm-admin 是一个管理PMM客户端的命令行工具，例如添加或者移除需要被监控的数据库实例

2.2.6注册pmm-client客户端到pmm-server上即可

pmm-admin config --server-insecure-tls --server-url=https://admin:admin@172.16.130.12:443
释义：

a)、172.16.130.12是PMM服务器的地址。
b)、443是默认端口号。
c)、admin/admin是默认的PMM用户名和密码。这是您用于登录PMM用户界面的同一个帐户
d)、server-insecure-tls客户必须使用安全通道向PMM服务器注册。如果使用http作为服务器URL，PMM将尝试通过https在端口443上进行连接。如果无法建立TLS连接，则会出现错误，您必须使用https以及相应的安全端口。

3.通过web页面添加MGR组复制监控

目前现有的MySQL MGR组复制在同一台主机上，使用3308,3309,3310三个端口隔离，搭建的MGR，其结构如下：

mysql> select *from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | d42b85f7-dc14-11ec-a892-78ac4455e2ec | 172.16.130.53 |        3308 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
| group_replication_applier | d79d8a68-dda8-11ec-95d3-78ac4455e2ec | 172.16.130.53 |        3309 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
| group_replication_applier | f0ad2d97-dda8-11ec-9dc1-78ac4455e2ec | 172.16.130.53 |        3310 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

在添加监控之前，在MGR上创建用于监控数据采集的数据库的数据库用户,开启performance_schema的监控指标

a)在MGR中创建用于数据采集的用户，接入到PMM中
mysql> create user pmm@'%' identified with mysql_native_password by 'password';
mysql>GRANT SELECT, PROCESS, REPLICATION CLIENT, RELOAD, BACKUP_ADMIN ON *.* TO 'pmm'@'%';

b)开启MySQL的performance_schema的SQL语句监控指标采集项
mysql>UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%statements%';   

下列5张表表示每个线程中记录存储SQL统计信息，以显示该线程最近监视的语句事件的CPU，当前语句、历史执行用作PMM监控数据采集和SQL分析
mysql> select * from performance_schema.setup_consumers  WHERE NAME LIKE '%statements%';
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| events_statements_cpu          | YES     |
| events_statements_current      | YES     |
| events_statements_history      | YES     |
| events_statements_history_long | YES     |
| statements_digest              | YES     |
+--------------------------------+---------+
5 rows in set (0.00 sec)

mysql> 

c)启用MySQL的innodb启用计数器，其参数后面可跟计数对象如log,metadata_table_handles_opened,metadata_table_handles_closed等，如果设置为ALL代表统计所有选项，负面影响就是由于每个计数器都会增加一定程度的运行时开销，因此请在生产服务器上尽量保守使用计数器功能，根据实际需求，开启特定对象的监控，用来诊断分析定位问题或监控特定指标项。

mysql>SET persist innodb_monitor_enable = all;

通过web页面方式添加MGR实例到监控中,具体操作如下图

另外可通过命令行方式增加监控的数据库

在安装pmm-client客户端的主机上，添加监控的MySQL实例
pmm-admin add mysql --username=username --password=password --tls --tls-skip-verify --tls-ca=pathtoca.pem --tls-cert=pathtocert.pem --tls-key=pathtocertkey.pem --server-url=http://admin:admin@172.16.130.12 --query-source=perfschema name 172.16.130.53:3308

如果开启了MGR的慢日志，则可以通过下列命令添加慢日志监控

pmm-admin add mysql --query-source=slowlog --size-slow-logs=1GiB --username=user --password=pass MYSQL_NODE 172.16.130.53:3309

其他具体命令方式添加MySQL的监控项，可参考官方示例：https://docs.percona.com/percona-monitoring-and-management/setting-up/client/mysql.html

4.PMM监控选项图示

将上述剩余的两个MGR节点，以同样的方式添加到pmm-server，等待pmm-server的数据采集大约30s之后，就可以看到对应的MGR状态情况了，如下示例 监控MGR状态，采集所使用的SQL，我们可以在被监控的主机上尝试开启general log来捕获这些系统表的数据统计SQL。

采集MGR监控状态的SQL：

SELECT conn_status.channel_name as channel_name, conn_status.service_state as IO_thread, applier_status.service_state as SQL_thread, 'N/A' as last_queued_transaction, 'N/A' as last_applied_transaction, 1 as info FROM performance_schema.replication_connection_status AS conn_status JOIN performance_schema.replication_applier_status_by_worker AS applier_status ON applier_status.channel_name = conn_status.channel_name WHERE conn_status.service_state = 'ON' and (SELECT SUBSTRING(@@VERSION,1,1) = 5);

SELECT COUNT_TRANSACTIONS_IN_QUEUE as transactions_in_queue, COUNT_TRANSACTIONS_CHECKED as transactions_checked_total, COUNT_CONFLICTS_DETECTED as conflicts_detected_total, COUNT_TRANSACTIONS_ROWS_VALIDATING as transactions_rows_validating_total, COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE as transactions_remote_in_applier_queue, COUNT_TRANSACTIONS_REMOTE_APPLIED as transactions_remote_applied_total, COUNT_TRANSACTIONS_LOCAL_PROPOSED as transactions_local_proposed_total, COUNT_TRANSACTIONS_LOCAL_ROLLBACK as transactions_local_rollback_total FROM performance_schema.replication_group_member_stats WHERE MEMBER_ID=@@server_uuid

当节点故障发生故障，观察监控界面状态变化

在MGR上使用压测工具benchmarksql尝试建仓，查看下PMM监控中MGR的同步延迟情况 benchmarksql数据建仓约10分钟左右，对应的MGR延迟逐渐增大

计算MGR节点延迟SQL,和事务执行情况，主要通过查询performance_schema.replication_connection_status表和 performance_schema.replication_applier_status_by_worker通过并行的channel做关联运算来获取MGR单住模式下，主节点和从节点的延迟的。LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMPSELECT conn_status.channel_name as channel_name, conn_status.service_state as IO_thread, applier_status.service_state as SQL_thread, conn_status.LAST_QUEUED_TRANSACTION as last_queued_transaction, applier_status.LAST_APPLIED_TRANSACTION as last_applied_transaction, LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 'rep_delay_seconds', LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP 'transport_time_seconds', LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP - LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP 'time_RL_seconds', LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_START_APPLY_TIMESTAMP 'apply_time_seconds', if(GTID_SUBTRACT(LAST_QUEUED_TRANSACTION, LAST_APPLIED_TRANSACTION) = '','0' , abs(time_to_sec(if(time_to_sec(APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP)=0,0,timediff(APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP,now()))))) `lag_in_seconds` FROM performance_schema.replication_connection_status AS conn_status JOIN performance_schema.replication_applier_status_by_worker AS applier_status ON applier_status.channel_name = conn_status.channel_name WHERE conn_status.service_state = 'ON' ORDER BY lag_in_seconds, lag_in_seconds desc

SELECT name, subsystem, type, comment, count FROM information_schema.innodb_metrics  WHERE status = 'enabled'
| name                                        | subsystem           | type           | comment                                                                                                                           | count       |
+---------------------------------------------+---------------------+----------------+-----------------------------------------------------------------------------------------------------------------------------------+-------------+
| metadata_table_handles_opened               | metadata            | counter        | Number of table handles opened                                                                                                    |      200753 |
| metadata_table_handles_closed               | metadata            | counter        | Number of table handles closed                                                                                                    |      200575 |
| metadata_table_reference_count              | metadata            | counter        | Table reference counter                                                                                                           |         138 |
| lock_deadlocks                              | lock                | counter        | Number of deadlocks                                                                                                               |           0 |
| lock_deadlock_false_positives               | lock                | counter        | Number of times a heuristic found a spurious candidate deadlock cycle in the wait-for graph                                       |           0 |
| lock_deadlock_rounds                        | lock                | counter        | Number of times a wait-for graph was scanned in search for deadlocks                                                              |      954074 |
| lock_threads_waiting                        | lock                | value          | Number of query threads sleeping waiting for a lock                                                                               |           0 |
| lock_timeouts                               | lock                | counter        | Number of lock timeouts                                                                                                           |           0 |
| lock_rec_lock_waits                         | lock                | counter        | Number of times enqueued into record lock wait queue                                                                              |           0 |
| lock_table_lock_waits                       | lock                | counter        | Number of times enqueued into table lock wait queue                                                                               |           0 |
| lock_rec_lock_requests                      | lock                | counter        | Number of record locks requested                                                                                                  |       23060 |
| lock_rec_release_attempts                   | lock                | counter        | Number of times we attempted to release record locks                                                                              |        2166 |
| lock_rec_grant_attempts                     | lock                | counter        | Number of times we attempted to grant locks for a record                                                                          |         273 |
| lock_rec_lock_created                       | lock                | counter        | Number of record locks created                                                                                                    |        1983 |
| lock_rec_lock_removed                       | lock                | counter        | Number of record locks removed from the lock queue                                                                                |        1983 |

监控MGR组复制的3个节点innodb引擎I/O使用情况

查看MGR的产生的锁情况，点击黄色六边形可具体查看详细信息

查看当前MGR主节点的SQL执行情况，同时根据需求进行query analytics查询分析

query analytics查询分析
SELECT /* pmm-agent:perfschema */ `performance_schema`.`events_statements_summary_by_digest`.`QUERY_SAMPLE_TEXT`, `performance_schema`.`events_statements_summary_by_digest`.`DIGEST`, `performance_schema`.`events_statements_summary_by_digest`.`SCHEMA_NAME` FROM `performance_schema`.`events_statements_summary_by_digest` WHERE DIGEST IS NOT NULL AND QUERY_SAMPLE_TEXT IS NOT NULL;

同样可以监控MGR所在主机的运行情况，CPU,MEMORY,I/O,NETWORK等

节点主机信息

后续的监控事项就不一 一展示描述了，大家可以自行下载，上手试一下，看10遍不如动手搭一次，心动不如行动。

5.卸载PMM-CLIENT

1、yum安装方式和二进制包方式

yum remove -y pmm2-client
yum remove -y percona-release

2、取消到pmm-server的注册

pmm-admin unregister --force

取消监控的节点或者客户端：

pmm-admin remove <service-type> <service-name>
service-type：
mysql, mongodb, postgresql, proxysql, haproxy, external

3、docker方式卸载pmm-client 总结起来3个字，1停2删3清 1.停止pmm-client 容器

docker stop pmm-client

2.删除pmm-client 容器

docker rm pmm-client

3.删除pmm-client的docker镜像

docker rmi $(docker images | grep "percona/pmm-client" | awk {'print $3'}) --force

4.清理卷组中的数据

docker volume rm pmm-client-data

6.总结

PMM监控管理工具 其实我更想叫它运管平台，而不是单纯的监控工具，毕竟是两个M(monitoring-and-management)，它已经比个别厂商的付费监控平台优秀的多了，而且是percona开源免费的，其优点如下：

• A)、采用C/S结构部署，分为pmm-client和pmm-server，docker方式部署较为简单高效易上手。
• B)、提供较为丰富的MySQL监控架构，如MGR，主从复制，PXC等，支持多种数据库监控接入，WEB UI界面指标可视化的仪表盘丰富。
• C)、除了提供较为丰富的MySQL多种存储引擎的监控指标，且对应监控项按需细化增删等。
• D)、同时根据采集监控的数据库指标，可以按需制定告警规则，以及根据监控数据提出数据库健康分析建议和评估。
• E)、其他方面除了支持监控MySQL数据库之外，还支持Cloud Database、PostgreSQL、MongoDB、HAproxy、ProxySQL等数据库以及中间件的监控。

如果大家有时间的话，建议不妨上手试一下，监控MGR、MS复制、中间件状态、主机负载情况，做日常性的监控看板，统筹多实例，且有跨多个厂商的数据库做集中运监管的，还是很不错的选择。书写中如果有纰漏和错误还请大家帮忙指出，谢谢。