去年冬天，监测我在一个数据中心里盯着一块屏幕看了整整两个小时。监测屏幕上是监测一条几乎不动的曲线——某台核心交换机的CPU利用率。运维老张说，监测这玩意儿要是监测突然跳上去，十分钟内他的监测手机就会响。这就是监测CMS在线监测最朴素的样子：不是炫技，是监测保命。

CMS，监测内容管理系统，监测听起来像给编辑发文章用的监测。但真正在生产环境里跑过的监测人知道，它更像一栋楼的监测承重墙。你平时感觉不到它，监测一旦裂了，监测整栋楼都慌。在线监测就是给这堵墙贴应变片。监测什么？不是只看服务器活没活着。那太糙了。

我见过一个案例。某省级媒体，每天凌晨两点自动发布第二天的稿件。有天早上编辑发现首页空了。查日志，CMS后台显示“任务执行成功”。但数据库连接池在凌晨1:58到2:03之间耗尽了。任务确实跑了，只是没连上库。在线监测如果只盯着HTTP 200，这事就漏了。得看连接池等待时间、慢查询数量、甚至PHP-FPM的进程堆积数。这些指标单看都正常，叠在一起才露出马脚。

监测的粒度决定你能不能睡个好觉。有个做电商的朋友，大促前给CMS加了个监测项：模板渲染耗时。平时80毫秒，大促时飙到1.2秒。不是服务器扛不住，是某个促销标签循环查了三百多次数据库。这种问题，CPU和内存曲线都好看得很。只有把埋点打到模板引擎里，才能抓住。

但监测太细也麻烦。我试过在一个中型CMS上开了两百多个指标，结果每天告警邮件比垃圾邮件还多。磁盘IO偶尔抖一下，告警；某个冷门接口响应慢了50毫秒，告警。后来砍到三十个核心指标，世界清净了。关键是要区分“症状”和“病因”。页面打不开是症状，数据库死锁是病因。监测要盯着病因，别被症状牵着走。

现在很多CMS自带监测面板，花花绿绿的图表。我一般先关掉。默认面板往往在骗人。比如它显示“缓存命中率98%”，听起来很棒。但那个2%的未命中，可能全是首页请求。首页每次回源查库，QPS一高就崩。你得自己写个脚本，把未命中的key按访问量排序。前十名里如果有首页，缓存策略就得重写。

还有个坑：监测数据本身也会骗人。有次半夜收到告警，说CMS发布接口超时。爬起来一看，监测脚本自己跑了二十分钟没返回。原因是它去请求一个被防火墙限速的URL。监测系统得独立于被监测系统。用CMS的API去监测CMS，等于让病人自己写病历。

我习惯在每台CMS服务器上留一个“后门”脚本。不经过Web层，直接读本地日志和系统状态。SSH进去一跑，三秒出结果。这个脚本不依赖任何外部服务，连数据库都不连。它只干一件事：把最近五分钟的error_log里带“Fatal”的行数、磁盘剩余空间、以及php-fpm的活跃进程数打出来。简单，但救命。有次磁盘满了，CMS后台登录白屏，就是这个脚本先发现的。

在线监测到最后，拼的不是技术，是经验。你知道哪些指标组合起来会出事。比如“内存使用率85% + 交换分区使用率10% + 平均负载2.0”，这三个一起出现，基本半小时内要OOM。这是看了三年告警总结出来的。书上不写，文档里没有。

别指望一套监测系统能管所有CMS。WordPress、Drupal、自研的Java CMS，监测重点完全不同。WordPress要盯wp-cron和插件表锁；Drupal看缓存表和BigPipe；自研的反而简单，因为你知道哪里最容易断。我现在的做法是：核心指标统一收，业务指标按CMS类型分。不追求大而全，追求“告警了我就知道去哪台机器上敲哪条命令”。

凌晨三点的告警短信，没人喜欢。但如果没有它，凌晨三点你就得在用户投诉电话里醒来。选一个吧。