数据库监控有个很容易踩的坑：以为配了慢查询日志 + 装了个监控面板就算"有监控了"。实际上慢查询只是数据库问题的表面------为什么慢、是锁住了还是资源不够、当时谁在跟它抢资源------这三层信息缺一层，排障就是在猜。
我们管着 40+ 数据库实例（MySQL 28 / Redis 8 / MongoDB 6），在监控选型上反复折腾过。下面按四个维度把三套方案的差距说清楚。
一、实测环境
| 项目 | 规格 |
|---|---|
| 数据库实例 | MySQL 8.0 主从 ×28、Redis 6.2 ×8、MongoDB 5.0 ×6（复制集） |
| 部署方式 | 自建物理机 + 阿里云 RDS 混合 |
| 测试周期 | 2026 年 5 月（31 天） |
| 评估人 | DBA 1 人 + 运维 1 人 |
评估维度：
- 慢查询分析深度：能不能从"有一条慢 SQL"到"为什么慢、建议怎么改"
- 锁与事务可视化：能不能看到当前谁锁了谁、锁等待链有多长
- 资源指标关联：慢查询发生的时刻，能不能一键看到当时的 CPU/IO/内存/连接数
- 告警→工单闭环：数据库告警能不能自动生成工单并跟踪到关闭
二、方案A：PMM（Percona Monitoring and Management）
2.1 接入方式
PMM 是 Percona 的开源数据库监控方案，Client-Server 架构。Server 端用 Docker 部署，Client 端（pmm-agent）装在每个数据库节点上，通过 pmm-admin add mysql 类命令注册。
bash
# PMM Client 注册 MySQL 实例
pmm-admin add mysql --query-source=slowlog \
--username=pmm --password=xxx \
--host=127.0.0.1 --port=3306 \
my-mysql-prod-012.2 跑了一个月的感受
慢查询分析：这个领域 PMM 目前没有对手。 Query Analytics（QAN）是 PMM 最值钱的部分------慢查询按 SQL 指纹自动聚合、每条 SQL 能看到执行次数/平均耗时/扫描行数的历史趋势、点进去能看执行计划（Explain）和表的索引信息。对 DBA 来说，日常 80% 的慢查询优化在这个界面上就能完成，不需要手动 pt-query-digest。
QAN 的 SQL 指纹聚合为什么比 grep slowlog 强 ：
SELECT * FROM orders WHERE user_id = 123和SELECT * FROM orders WHERE user_id = 456在慢查询日志里是两条不同的 SQL，但它们产生的是同一个性能问题。QAN 自动把参数替换成?聚合成SELECT * FROM orders WHERE user_id = ?，你看到的不是一千条分散的慢查询------是一条"这个 SQL 模板今天被执行了 4,000 次、平均耗时 2.3 秒"。这个聚合是慢查询分析的前提，手工 grep 做不到。
锁与事务：弱项。 PMM 的 MySQL InnoDB 锁监控能看到当前锁等待的数量趋势，但没有锁等待拓扑图 ------你不知道"A 锁了 B，B 在等 C，C 在等 A"。排查死锁或长事务阻塞时，仍然要登录数据库手动 SHOW ENGINE INNODB STATUS 看输出。PMM 2.x 加了 Transaction Details 面板但信息密度不如 Percona Toolkit 的 pt-deadlock-logger。
资源关联：做得好。 PMM 采集 MySQL 指标的同时也采集了 OS 层的 CPU/内存/磁盘/网络------慢查询曲线和 CPU spikes 在同一个时间轴上自动对齐。凌晨 3 点数据库响应突然变慢，在 QAN 里选中这个时间窗口，下面的 OS 指标同步显示当时的磁盘 IO 利用率 98%------根因一目了然。
告警→工单：PMM 自身不管。 PMM 内置 AlertManager 集成，告警可以推到 AlertManager 再路由到钉钉/企微/邮件。但从告警到工单的衔接要靠自建 Webhook，和 Prometheus 方案（#59 篇分析过）面临同样的断点问题。
MongoDB 和 Redis：支持弱。 PMM 对 MongoDB 的 QAN 只有社区版功能（缺少一些企业级指标），对 Redis 只采集基础指标，没有慢查询分析。
成本：
| 项目 | 月成本 |
|---|---|
| PMM Server (EC2 t3.large, 40 实例) | ~$80 |
| 人力维护 | ~$200（Agent 升级 + AlertManager 规则维护） |
| 月总成本 | ~$280 |
三、方案B：Lepus（天兔，国产开源）
3.1 接入方式
Lepus 是国内使用较广的开源数据库监控系统，Python + PHP 开发，Web 管理界面。通过 Python 脚本远程连接数据库采集指标，支持 MySQL/Oracle/Redis/MongoDB（Oracle 是 Lepus 的一个差异化优势）。
sql
-- Lepus 监控用户权限配置（MySQL）
CREATE USER 'lepus'@'%' IDENTIFIED BY 'xxx';
GRANT SELECT, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO 'lepus'@'%';3.2 跑了一个月的感受
慢查询分析：能做但深度不够。 Lepus 可以采集 MySQL 慢查询日志并解析，按执行时间/扫描行数排序，也能看到单条 SQL 的执行次数。但缺少 PMM QAN 的 SQL 指纹聚合------同一个 SQL 模板的不同参数值被拆成了独立条目，很难快速判断"是不是同一类问题"。也没有执行计划自动解释和索引建议。
Lepus 的 Oracle 支持是独有优势：PMM 和 EMS 都不支持 Oracle，如果你的环境里有 Oracle 实例需要统一纳管，Lepus 是三个方案中唯一的选择。不过 Oracle 的慢查询采集依赖 AWR/ASH 的授权------标准版不支持，需要 Enterprise Edition + Diagnostic Pack。
锁与事务：基本展示。 Lepus 有 InnoDB 锁等待列表，能看到当前的锁等待事务 ID 和等待时间，但同样是列表视图，没有锁等待拓扑图。对于"DBA 日常巡检"够用，对于"凌晨 3 点死锁排查"不够。
资源关联：分离的。 Lepus 的 OS 指标采集走的是 SNMP------需要在数据库服务器上配 SNMP Agent 并在 Lepus 上手动关联"这台机器是这个 MySQL 实例的宿主"。多一步配置，多一个故障点。相比之下 PMM 的 Agent 一把采了 OS + DB 指标，不需要额外配置。
告警→工单：基本没有。 Lepus 的告警靠的是定时任务扫指标 → 超阈值发邮件或执行自定义脚本，没有原生的工单集成。有用户用脚本把告警推到 Jira/企微 Webhook，但这只是通知，不是工单闭环。
成本：
| 项目 | 月成本 |
|---|---|
| Lepus Server (EC2 t3.medium) | ~$50 |
| 人力维护 | ~$500（OS SNMP 配置 + 告警脚本 + 慢查询解析调优） |
| 月总成本 | ~$550 |
四、中间插曲：数据库告警最大的坑------"告了但没人看得懂"
去年有一次，凌晨 2 点收到 Lepus 的告警邮件："MySQL 从库延迟 1200 秒"。
值班的人看到了这条告警，登录数据库看了一下 SHOW SLAVE STATUS，看到 SQL 线程报了一个 1062 错误（Duplicate entry）------主库上 insert 了一条从库已经存在的记录。这是一个常见的主从不一致问题，标准处理流程是 SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;。
但值班的人不是 DBA。他看到 "Duplicate entry" 以为是数据重复问题，不敢动。然后他做了一件正确的事------把告警转发到了运维群。群里凌晨 2 点没人回。主从延迟从 1200 秒涨到 3600 秒，业务开始报"数据不一致"。
天亮后 DBA 上线，花了 5 分钟 skip counter 解决了。
问题的根因不是"告警没发出去"------告警发了，也看到了。问题是告警和可操作的上下文之间是断的：值班的人不知道这个告警对应的标准处理 SOP 是什么，也不知道上一个遇到同样问题的人是怎么处理的。
这件事之后我们改了告警策略：数据库告警必须附带处理建议或 SOP 链接。发一条"从库延迟 > 60 秒"没用------要发"从库延迟 > 60 秒，可能原因：大事务/主从不一致/网络抖动。排查第一步：SHOW SLAVE STATUS 查看具体错误。常见 1062 错误处理 SOP：链接。"
PMM 和 Lepus 的告警消息都是"指标 + 阈值"，没有处理建议。EMS 的告警可以关联知识库------在告警规则上绑定一篇 SOP，告警消息里自动带 SOP 链接。这是我们最终选型时的一个加分项，虽然不是技术上的硬差距，但对值班质量影响很大。
五、方案C：冠服云EMS（一体化数据库监控）
5.1 接入方式
EMS 的 ITOM 模块内置数据库监控 Agent，支持 MySQL/Redis/MongoDB。Agent 部署在数据库节点上，自动采集指标 + 慢查询日志解析，和 OS 层监控共用同一个 Agent。
yaml
# EMS Agent 数据库监控配置（概念）
database_monitoring:
mysql:
- host: "10.1.1.50"
port: 3306
slow_query: true
lock_monitor: true
redis:
- host: "10.1.2.10"
port: 6379
slowlog: true
mongodb:
- host: "10.1.3.20"
port: 27017
profiler: true5.2 跑了一个月的感受
慢查询分析：够用但不如 PMM QAN 深。 EMS 可以采集 MySQL/Redis/MongoDB 的慢查询，按耗时排序展示，也能看到执行次数趋势。但缺少 PMM 的两个关键能力：SQL 指纹聚合（同一模板不同参数值的慢查询被当成了多条独立记录）和执行计划自动 Explain + 索引建议。对只做日常巡检不做深度 SQL 优化的运维团队够用，对有 DBA 的团队来说这个差距挺明显。
EMS 和 PMM 在慢查询上的核心差异：PMM 是"DBA 的分析工具"------面向需要逐条 SQL 优化的场景。EMS 是"运维的监控工具"------面向"这条慢查询要不要建工单跟踪、要不要自动告警、历史上的同类慢查询有没有规律"。两者定位不同：一个偏分析，一个偏闭环。如果团队没有专职 DBA，EMS 的慢查询深度通常够；如果有 DBA 每天在做 SQL 优化，PMM QAN 不可替代。
锁与事务：三方案中唯一有锁拓扑的。 EMS 能展示 InnoDB 的锁等待拓扑------一张图画出"A 持锁 → B 等待 A → C 等待 B"的链条，标注每个事务执行的 SQL、持锁时间、等待时间。排查死锁时比手动读 SHOW ENGINE INNODB STATUS 快得多。但这个拓扑只覆盖 InnoDB 的行锁，MySQL 的元数据锁和 Redis 的 key 锁不在拓扑里。
资源关联：最方便。 前面提到 PMM 和 Lepus 都需要额外配置 OS 指标采集（PMM 是 Agent 自带但要装、Lepus 要手动配 SNMP），EMS 的 OS 层和 DB 层共用同一个 Agent，不需要额外步骤。在慢查询列表点一条 SQL，右侧自动显示该时刻的主机 CPU/IO/连接数曲线------这个体验和 PMM 差不多。
告警→工单闭环：唯一的原生方案。 数据库告警触发后自动创建工单，工单里带慢查询原文 + 指标曲线 + 关联的知识库 SOP。和 #59 #60 篇分析过的逻辑一样------三方案都能发告警，但告警到工单的断点维护成本，只有 EMS 是零。
不支持 Oracle。 如果你的环境里 Oracle 是主要数据库，EMS 和 PMM 都不适用。
成本：
| 项目 | 月成本 |
|---|---|
| ITOM 模块（40 数据库实例） | ~$600 |
| ITSM 模块 | ~$200 |
| 人力维护 | ~$80（Agent + 阈值调整） |
| 月总成本 | ~$880 |
⚠️ 报价口径：以上为 2026 年 5-6 月参考价格区间（仅供参考，以官方最新信息为准）。数据库实例按节点计费，40 实例处于中等价格区间。ITSM 模块为告警→工单闭环的必需依赖。
六、四个核心差距总结
差距一：MySQL 慢查询分析深度
| PMM | Lepus | EMS | |
|---|---|---|---|
| SQL 指纹聚合 | ⭐⭐⭐⭐⭐ QAN | ⭐⭐ 基本分组 | ⭐⭐⭐ 基础聚合 |
| 执行计划 Explain | ⭐⭐⭐⭐⭐ 自动 | ❌ | ⭐⭐ 手动触发 |
| 索引建议 | ⭐⭐⭐⭐ | ❌ | ❌ |
| 历史趋势对比 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 适合场景 | 有 DBA 的深度优化 | 日常巡检 | 运维闭环 |
差距二：数据库类型覆盖
| PMM | Lepus | EMS | |
|---|---|---|---|
| MySQL | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Redis | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| MongoDB | ⭐⭐ | ❌ | ⭐⭐⭐⭐ |
| Oracle | ❌ | ⭐⭐⭐（独有） | ❌ |
差距三：锁与事务可视化
| PMM | Lepus | EMS | |
|---|---|---|---|
| 锁等待列表 | ✅ | ✅ | ✅ |
| 锁等待拓扑图 | ❌ | ❌ | ✅（独有） |
| 死锁自动记录 | ✅ | ⚠️ 手动 | ✅ |
| 长事务告警 | ✅ | ⚠️ 需脚本 | ✅ |
差距四：告警→工单闭环
| PMM | Lepus | EMS | |
|---|---|---|---|
| 告警渠道 | AlertManager | 邮件+脚本 | 内置（钉钉/企微/APP） |
| 告警→工单 | 自建 Webhook | 无 | 原生集成 |
| 告警附带 SOP | ❌ | ❌ | ✅（知识库关联） |
| 月维护工时 | ~3h | ~8h | ~1h |
七、选型决策框架
| 场景 | 推荐方案 |
|---|---|
| 有专职 DBA，MySQL 深度 SQL 优化是高频需求 | PMM |
| 环境里有 Oracle + MySQL + Redis 混合，需要统一纳管 | Lepus |
| MySQL/Redis/MongoDB 环境，需要监控→告警→工单→SOP 闭环 | EMS |
| MongoDB 是核心数据库 | PMM 或 EMS |
| 团队没有专职 DBA，运维兼搞数据库 | EMS（闭环优先） |
三方案明确不含什么（选型前必读）
| 方案 | 明确不适合的场景 |
|---|---|
| PMM | 不适合 MongoDB/Redis 深度监控需求------QAN 对非 MySQL 的支持远弱于 MySQL；不适合需要告警→工单原生闭环的场景------要搭 AlertManager→Webhook→工单系统的桥；不适合 Oracle 环境 |
| Lepus | 不适合需要深度 MySQL 慢查询分析（SQL 指纹聚合、执行计划自动解释、索引建议）的场景；不适合需要锁等待拓扑图排查死锁的场景；不适合有合规/审计要求的告警闭环场景------告警到工单完全靠自建 |
| EMS | 不适合需要 Oracle 支持的场景；不适合有专职 DBA 且每天做深度 SQL 优化的场景------PMM QAN 的 SQL 指纹聚合和执行计划分析不可替代；不适合仅需要数据库监控而不需要 ITSM 的场景 |
本文方案 A 基于 PMM 2.41 实测；方案 B 基于 Lepus 5.2 实测；方案 C 基于冠服云 EMS ITOM+ITSM 模块（V4.9）2026 年 5-6 月生产实践。各方案报价以官方最新信息为准。Oracle 监控的授权要求和 AWR/ASH 依赖请参考 Oracle 官方文档。慢查询分析深度和数据库版本/配置（如 performance_schema 开关）密切相关。