一套监控系统，帮我揪出了3个隐藏的性能问题

前言

上个月，测试组的同事找我，说有个问题排查了两天还没定位到。

我问他查了什么。他说：日志翻了、服务器登了、CPU 和内存也手动敲命令看了，就是找不到原因。

我听完叹了口气——这不是能力问题，是工具问题。

两天后，我花了两周时间搭了一套监控系统。现在同样的问题，2小时就能搞定。

今天把搭建过程、踩过的坑、以及上线后揪出来的几个问题，一次性写出来。

一、监控到底解决什么问题

很多人觉得监控就是"看个大盘"，其实不是。

监控解决的是一个核心矛盾：问题发生的时候你不在，但你又需要知道发生了什么。

举个例子：某个服务在凌晨3点 CPU 飙到95%，持续了20分钟又自动恢复了。第二天用户说"昨晚系统有点卡"，你去查日志——日志滚过了，服务器资源早就正常了。

没有监控，你只能靠猜。有了监控，趋势图一拉，凌晨3点那个波峰清清楚楚。

监控的价值：让你不在现场也能"看见"问题。

二、两层监控架构

第一层：Grafana + Prometheus（主力栈）

覆盖 JVM、服务器资源、服务器进程、数据库。这层负责"广度"——打开 Grafana，所有东西都在一个界面里。

第二层：PMM（数据库专项）

覆盖 MySQL 慢查询分析、锁等待、连接数。这层负责"深度"——精准定位到具体哪条 SQL 慢。

为什么分两层？因为没有一个工具能同时做到"广"和"深"。Grafana 什么都能看，但数据库分析不如 PMM 专业；PMM 数据库分析强，但它只能看数据库。

两层配合：先用 Grafana 定大方向，再用 PMM 钻进去挖细节。

三、仪表盘选型：踩坑最多的一步

说实话，搭这套系统最耗时的不是部署 Prometheus——是选仪表盘。

Grafana 社区仪表盘成千上万，质量参差不齐。我踩过这些坑：

• 有的数据不准，Prometheus 采集的指标和面板展示的对不上
• 有的布局反人类，关键指标藏在角落里
• 有的带一堆我们不需要的 GPU、K8s 指标

经验：先列清楚要监控什么，再去找仪表盘，反过来做会浪费大量时间。

最终按4个维度搭建了目录结构：JVM监控、Linux监控、MySQL监控、Windows监控。

每个文件夹对应一个维度，团队成员打开 Grafana 就知道去哪找，不用每次问我。

四、两个踩坑记录

坑1：PMM 新版本命令"暗改"

PMM 部署完之后，我照着网上的教程添加 MySQL 监控实例，命令敲下去——报错。

查了半天，对比官方文档才发现：新版本命令语法变了。

## 旧命令pmm-admin add mysql --username=pmm --password='pass' --query-source=perfschema <name><ip:port>## 新命令pmm-admin add mysql --username pmm --password 'pass' --server-insecure-tls --query-source=perfschema <name><ip:port>

两个变化：参数赋值从 = 改成空格分隔 + 新增 --server-insecure-tls。

就这么个小变化，花了我大量时间。教训：官方文档优先，社区教程可能版本滞后。

坑2：仪表盘不是拿来就能用

社区仪表盘下载下来，大部分需要二次开发。刷新频率、聚合方式、筛选条件都要改。

没有捷径，就是对着 Grafana 的 JSON 配置一点点改。改完记得导出备份——别问我怎么知道的。

五、揪出了3个问题

搭监控不是为了展示"我们有监控"，是为了发现问题。

问题1：云服务资源飙升

通过 JVM Overview，发现某个云服务产品处理数据时，CPU 和内存占用异常偏高。

这类问题靠人工盯抓不到——它不是一直高，而是在特定处理阶段才飙升，处理完又降下来了。第二天去看服务器，一切正常，什么痕迹都没有。

有了监控之后，趋势图一拉，波峰清清楚楚。哪个接口触发的、持续了多久、峰值是多少，全部有数据。

问题2：终端产品磁盘快满了

通过 Linux Node Exporter 总览表，发现某个终端产品磁盘使用率持续偏高。

5台服务器的核心指标一张表：CPU、内存、磁盘、IOPS、连接数、带宽。扫一眼就能发现异常。

磁盘满了没发现，轻则写不了日志，重则直接宕机。这种问题靠人工巡检，很难保证不漏。

问题3：单体系统慢查询

这是 PMM 的主场。通过慢查询分析，定位到某个单体系统存在部分慢查询——具体到哪条 SQL、执行了多久、扫描了多少行。

Grafana 能看全局 QPS、连接数、CPU 等宏观指标，但精准定位到 SQL，还是得靠 PMM。广度和深度缺一不可。

六、两个意外收获

测试团队省了大量时间。 以前写测试报告，指标全靠手动敲命令收集。现在直接从仪表盘截图，数据现成的。测试同事说，光这一项就省了不少加班时间。

开发团队定位更快了。 以前排查问题第一步是"登录服务器敲 top 和 free"。现在直接打开 Grafana。有个同事说："以前排查问题像盲人摸象，现在至少能看见大象长什么样了。"

七、还没做的事

目前有个明显缺口：没有告警规则。

现在的模式是"人去看仪表盘发现问题"。半夜出了问题怎么办？

下一步打算接入 Prometheus Alertmanager，实现自动告警：CPU 持续超80%、磁盘超90%、慢查询突增——自动通知。

总结

投入：仪表盘选型 + PMM 踩坑 + 仪表盘定制

产出：排查问题从2天→2小时；发现3个隐藏问题；测试和开发效率双提升

投入产出比，值得。

如果你的团队还在靠"人肉排查"——登服务器、敲命令、翻日志——认真考虑搭一套监控吧。不需要一步到位，先从最痛的点开始。

我们从 JVM 和服务器资源起步，后来加了 PMM，再后来加了进程监控。一步一步来，但一定要开始。

你在项目里踩过什么监控相关的坑？或者有什么好用的仪表盘推荐？评论区聊聊，说不定能帮到其他同学。

觉得有用的话，转发给你的团队吧。

「启言的码农日常」—— 后端·运维·架构·管理，正在成为全栈的电力工程师。