服务器半夜挂了三次，2026年我才真正搞明白监控该怎么做

讲一个上个月发生的真事。

凌晨两点半，手机震了。一条短信：「网站打不开了」。我爬起来看——服务器CPU 100%，MySQL挂了，Nginx还在跑但502。重启MySQL，好了。继续睡觉。三点十分又挂了。再重启。四点又挂。那晚基本没睡。

第二天查原因。一台跑了三年的阿里云轻量服务器，2核4G，上面塞了6个WordPress站。最近其中一个站突然被爬虫盯上，每小时几千个请求全打在搜索接口上。MySQL连接池打满，连带其他5个站全挂。

问题出在哪？不是服务器配置不够，是监控形同虚设。之前装过Prometheus+Grafana，配好之后就再没看过。报警阈值设得太宽——CPU到95%才报警，但MySQL在70%的时候已经扛不住了。

这次彻底重做了监控，几个关键改动：

1. 报警阈值调紧：CPU 60%、MySQL连接数超过80%就报警。宁可多报几次假的，不能漏掉真的。

2. 加了慢查询监控：超过3秒的SQL自动记录+企微通知。发现那个搜索接口根本没有索引，全表扫描。

3. 爬虫限流：Nginx加了limit_req，单IP每秒最多5个请求。多的直接503，不往后端传。

4. 进程级监控上线：用atop盯着MySQL进程的内存和IO，memleak能提前发现。

前后折腾了三天。现在再没半夜被叫起来过。说实话，监控这事就是「不出事的时候觉得多余，出事了才发现根本没有」。早点弄好，少掉几次头发。

标签： 服务器监控 mysql 故障排查 运维经验 Nginx