在上一篇文章中，我们实际测试了 dbops1.5 的监控告警机制，效果如何，大家可以参考之前的内容：
dbops1.5 强力升级：支持 Prometheus 全家桶，监控 MySQL 更简单(四)
今天，作为该系列的最后一篇文章，我将重点介绍 dbops1.5 在监控方案中的具体优化和改进，让大家更清晰地理解如何在实际环境中应用它。
前言
在选择监控方案时，有人会问：dbops 的 Prometheus 方案和 Percona 的 PMM 监控方案哪个更好？答案其实没有绝对的好坏之分，这取决于你的需求和使用场景。
PMM 是由数据库领域的专业公司 Percona 开发的开源产品，经过大量的打磨和优化，功能强大且开箱即用。对于大多数企业，尤其是中小型企业，PMM 都是非常不错的选择。
dbops 的 Prometheus 方案更适合那些想深入学习 Prometheus 全家桶的技术爱好者或者想自行定制监控系统的开发者。它可以作为一个起点，帮助你更好地理解监控体系背后的工作原理。
所以，二者并不存在绝对的可比性，而是适用场景不同。
一、dbops 借鉴了 PMM 的哪些功能？
dbops 在设计中确实借鉴了 PMM 的部分功能，但我们没有做简单的 "照搬"，而是根据实际需求进行了修改和优化。目前，dbops 仅在以下两处使用了 PMM 的开源技术：
1. Grafana 的 Dashboard
我们在 dbops 中使用了 PMM 提供的 Grafana Dashboard，你可以从 GitHub (https://github.com/percona/grafana-dashboards) 上获取到这些仪表板。
但需要注意的是，由于 PMM 的底层时序数据库采用的是 VictoriaMetrics 而不是 Prometheus，因此 PMM 的仪表板不能直接在 Prometheus 上使用。为此，官方提供了一个 Python 脚本来将其转换为 Prometheus 兼容格式，脚本的使用方式如下：
misc/convert-dash-from-PMM.py dashboards/Disk_Details.json复制
当然，转换后还会有一些小问题，我已经为其中一个通用问题提交了 PR(https://github.com/percona/grafana-dashboards/pull/1631)。
还存在一些非通用的兼容性小问题，虽然不多，但我也没有专门统计。为了不影响大家使用，我已经将所有修复都集成到了 dbops 的代码中，避免大家踩坑。
2. dbops 支持使用 PMM 的 node_exporter 和 mysqld_exporter
在 dbops 中，我们允许用户选择使用 PMM 的 exporter 工具。默认情况下，dbops 会使用自带的 exporter，但你也可以通过配置 mysqld_exporter_install_type 选项来切换到 PMM 的 exporter。
mysqld_exporter_install_type: dbops # dbops, pmm, package复制
PMM 的 exporter 拥有更强大的功能，支持更多的监控选项，并且针对 Percona Server 进行了优化，但不支持 MySQL 8.4。如果你选择使用 PMM 的 exporter，dbops 会自动安装并以默认配置启动 exporter 服务，具体配置参考 dbops 文档仓文档 (未写，待补充)。
二、dbops 相较于 PMM 的独特优势
虽然 PMM 功能强大，但 dbops 也有其独特的优势，特别是在某些特定场景下表现得更为出色：
裸机部署方案：dbops 不依赖任何虚拟化或容器技术，适合那些需要直接在物理机上运行监控的用户。
支持 MySQL 8.4：dbops 率先支持 MySQL 8.4 的监控和告警，而目前 PMM 还未支持这一版本。
自动化邮箱告警配置：dbops 提供了简单便捷的邮箱告警配置，开箱即用，非常适合那些希望快速部署并获得即时告警的团队。
三、深入剖析：dbops 如何支持 MySQL 8.4 的监控
官方的 mysqld_exporter 和 PMM 的 mysqld_exporter 均不支持 MySQL8.4 监控，为了支持 MySQL 8.4 的监控，dbops 进行了多项优化和改进，确保在新版 MySQL 中的所有监控项都能正常工作。
1. mysqld_exporter 对 MySQL 8.4 的支持
dbops 使用自带的 mysqld_exporter 来监控 MySQL 实例。与官方的 mysqld_exporter 不同，dbops 的版本基于官方开发版的源码编译，因此支持 MySQL 8.4。
2. Grafana Dashboard 对 MySQL 8.4 的支持
由于 MySQL 8.4 的部分监控指标名称与 MySQL 5.7 不一致，直接使用官方的 Grafana Dashboard 会遇到问题。例如：
MySQL 8.4 中的
slave_status 改为 replica_status
slave_io_running 改为 replica_io_running
slave_sql_running 改为 replica_sql_running
为了解决这些问题，dbops 添加了一个自定义的 Prometheus 规则文件，将不兼容的指标映射到兼容的格式：
路径：/usr/local/prometheus/rules/mysql_84_compatibility.yml
groups:
- name: mysql_84_compatibility
rules:
- record: mysql_slave_status_seconds_behind_master
expr: mysql_slave_status_seconds_behind_master or mysql_slave_status_seconds_behind_source
- record: mysql_slave_status_slave_io_running
expr: mysql_slave_status_replica_io_running or mysql_slave_status_slave_io_running
- record: mysql_slave_status_slave_sql_running
expr: mysql_slave_status_replica_sql_running or mysql_slave_status_slave_sql_running复制
未来，dbops 将继续完善这些规则文件，确保兼容更多的监控项。
四、其他功能与优化
1. 新增主机和 MySQL 实例的告警项
为了提供更全面的监控，dbops 为主机和 MySQL 实例开发了多项告警规则，涵盖了 CPU、内存、磁盘等资源的使用情况。在此路径定义：
路径：/usr/local/prometheus/rules/
2. 自动化 Dashboard 加载
dbops 会自动加载 dbops 自带的 Grafana Dashboard 文件，在此路径定义：
路径：/usr/local/grafana/conf/provisioning/dashboards/
3. Go 语言工具助力 Exporter 自动化注册
为了简化 exporter 的注册过程，dbops 使用 Go 语言开发了一款小工具，方便用户自动为 exporter 打标签并注册。dbops1.5 版本可以在此路径找到源码：
路径：/usr/local/dbops/mysql_ansible/exporterregistrar
4. 自动发送告警邮件
dbops 支持自动发送告警邮件，用户只需在配置文件中填写邮箱地址，dbops 会自动发送告警邮件。部署后，用户可以在 usr/local/alertmanager 路径下找到告警邮件的邮箱设置和告警字样模板。
路径：/usr/local/alertmanager/alertmanager.yml
路径：/usr/local/alertmanager/alertmanager.tmpl
五、注意事项：dbops 不支持 Grafana 11
虽然 dbops 支持 Prometheus 全家桶的自定义安装，但需要注意的是 Grafana 11 版本不兼容 dbops 的部分功能。原因是 PMM 的 Dashboard 使用了已被弃用的 AngularJS，而 Grafana 11 完全切换到了 React 框架。如果使用 Grafana 11，某些面板将无法显示，因此建议大家暂时使用 Grafana 10.x 版本。
grafana_package: grafana-enterprise-10.4.6.linux-amd64.tar.gz复制
六、总结
通过这几篇文章的讲解，我相信大家已经对 dbops 的监控体系有了更深入的了解。如果你有任何问题或建议，欢迎在评论区留言与我交流。
