上一篇排查中，我的 WordPress 博客因为一批携带 Sogou web spider/4.0 User-Agent 的异常高频请求，出现了严重的服务器资源耗尽问题。
故障高峰时：
Load Average ≈ 9
CPU idle = 0%
PHP-FPM Socket 队列 = 510 / 511
大量请求返回 499 / 502
WordPress 后台间歇性 502
最终通过 EdgeOne 在边缘节点直接拦截：
User-Agent: *Sogou*
→ Block
服务器迅速恢复：
PHP-FPM Socket：
510 / 511
→
0 / 511
CPU idle：
0%
→
最高 97%
后台本机测试：
连续 5 次 HTTP 200
问题虽然解决了，但这次故障也暴露出了另一个问题：
我的 ECS 缺少一套足够直观、能够保留历史数据并主动报警的服务器监控体系。
如果以后再次出现 CPU 打满、内存异常、磁盘空间不足或者公网带宽逼近上限，我不希望还是等到 WordPress 出现 502 后，再临时 SSH 登录服务器抓现场。
因此，在处理完 Sogou 异常流量之后，我继续把阿里云 ECS 的主机监控和报警体系补了起来。
一、为什么在这次 502 之后决定补齐云监控
这次故障能够最终定位，主要依赖服务器上的实时检查。
例如：
uptime
vmstat
free -h
ps
ss
这些命令帮我确认了：
CPU 已经完全没有空闲
PHP-FPM 是主要 CPU 消耗者
内存并没有耗尽
FastCGI 等待队列已经接近上限
这些数据当然非常有用。
但问题在于，它们更多是：
故障发生以后，再手工进入服务器抓现场。
如果我没有恰好发现后台 502，或者服务器负载只是短时间异常后自行恢复，那么很多现场数据就可能已经丢失。
更合理的方式应该是：
服务器持续采集指标
↓
保存历史趋势
↓
超过阈值
↓
主动报警
↓
再决定是否需要 SSH 深入排查
因此，这次故障解决后，我没有继续马上升级 ECS，而是先把监控补起来。
二、ECS 自带基础监控，但信息还不够完整
其实阿里云 ECS 本身已经能看到一些基础监控。
例如：
- CPU
- 公网流量
- 公网带宽
- 网络包
- 部分实例级指标
我最开始也是在 ECS 控制台里查看最近 7 天的公网带宽。
从当时的数据看，公网流出大部分时间只有：
约 200～300 Kbit/s
偶尔出现：
约 500～800 Kbit/s
而服务器购买的公网固定带宽是：
2 Mbps
因此初步已经能够判断：
公网带宽并不是这次 502 的瓶颈，而且目前也没有立即从 2 Mbps 升级到 5 Mbps 的必要。
但我同时发现了一些监控面板仍然显示：
暂无数据
尤其是：
- 内存使用率
- 系统 Load
- 磁盘使用率
- 操作系统网卡
- 进程等
这就需要服务器内部的监控 Agent。
三、一度进入云监控 2.0，但发现对个人博客来说太重了
从 ECS 页面点击“安装云监控插件”以后，我最初进入了阿里云的云监控相关页面。
现在阿里云已经有一套新的：
云监控 2.0
进入「接入中心 → 云服务器 ECS」以后，我发现这里会进一步引导开通企业云监控、Prometheus 等能力。
对于大型系统、多服务器、容器、Prometheus、日志关联和统一可观测体系，这套方案当然更完整。
但我的需求其实很简单：
一台 WordPress ECS
↓
看 CPU
看内存
看 Load
看磁盘
看公网带宽
↓
异常时给我发报警
如果只是为了这些基础需求，就把企业云监控、Prometheus、日志采集等整套体系全部接进来，对我来说有些过于复杂。
因此，我没有继续走云监控 2.0 的接入流程。
四、传统「主机监控」入口其实还在
随后我重新回到云监控传统页面。
左侧仍然可以看到：
云资源监控
→ 主机监控
进入以后，马上发现了一个关键问题。
我的 ECS 并不是从来没有安装过 Agent。
页面显示：
Agent 版本：2.1.56
Agent 状态：已停止
同时：
CPU：无数据
内存使用率：无数据
磁盘：无数据
这也解释了为什么以前很多操作系统级监控一直没有数据：
Agent 已经存在，但早就停止运行了。
五、没有继续恢复旧 Agent，而是直接升级
页面提供了：
批量安装或升级插件
于是我选中当前 ECS，准备升级。
这时阿里云弹出提示：
本次安装（升级）将安装 LoongCollector 采集器。
同时还提醒，如果服务器以前使用过 iLogtail，升级可能涉及 Logtail/LoongCollector 的兼容和配置迁移。
我的服务器没有依赖旧 iLogtail 做关键业务日志采集，因此确认后直接进行了升级。
整个过程没有修改 WordPress、Nginx、PHP-FPM、Redis，也没有重启 ECS。
六、Agent 从 2.1.56 升级到了 4.0.0
升级完成以后，再回到「主机监控」：
Agent 版本：4.0.0
Agent 状态：运行中
而之前一直显示“无数据”的几个指标也立即开始出现：
CPU：25.2%
内存使用率：44.02%
磁盘使用率：50.96%
这个结果也让我更加确定：
之前看不到操作系统监控，并不是 ECS 本身不支持，而是旧 Agent 已经停止工作。
七、终于可以直接看到 CPU、内存和系统 Load
进入：
主机监控
→ 监控图表
→ 操作系统监控
已经能够看到：
- CPU 使用率
- 内存使用率
- 系统平均负载
- 磁盘使用率
- 磁盘读写
- IOPS
刚恢复监控时，数据大致为：
CPU：
约 20%～30%
内存：
约 44%
磁盘：
约 51%
系统 Load 则仍然残留着之前故障时期的影响。
例如：
1 分钟 Load
下降最快
5 分钟 Load
随后下降
15 分钟 Load
下降最慢
这和之前服务器终端里的观察完全一致。
八、为什么「1 小时」有数据，而「1 天」暂时没有
刚升级 Agent 后，还有一个很容易产生误解的现象。
查看：
1 小时
已经可以看到监控曲线。
但切换到：
1 天
很多操作系统指标仍显示：
暂无数据
原因其实很简单。
旧 Agent 已经停止运行，新的 4.0.0 Agent 是刚刚才开始采集。
因此：
15:43 以前
没有 Agent 数据
15:43 以后
开始持续采集
云监控不会凭空补回过去没有采集到的内存、Load、磁盘等操作系统数据。
所以只需要让 Agent 持续运行。
几小时、一天、几天以后：
6小时
12小时
1天
3天
7天
这些时间范围自然就会逐渐积累完整的监控曲线。
九、网络监控也比以前完整很多
继续切换到：
网络监控
可以看到：
- 网卡带宽
- 网卡流入包数
- 网卡错误包
- 网络连接数
- VPC 公网带宽
- 公网流出带宽使用率
其中对我最有价值的是：
(ECS) IP 维度公网流出带宽使用率
因为我的服务器购买的是：
2 Mbps 固定公网带宽
这个百分比可以直接回答：
2 Mbps 到底够不够。
从恢复后的曲线看：
大部分时间：
约 5%～20%
部分峰值：
约 20%～35%
最高：
接近 40%
也就是说，即使按照 2 Mbps 上限计算：
40% ≈ 0.8 Mbps
20% ≈ 0.4 Mbps
10% ≈ 0.2 Mbps
当前距离真正跑满 2 Mbps 还有明显余量。
因此至少现阶段：
公网带宽没有必要升级。
十、既然监控已经恢复，就顺手把报警也补起来
光有监控还不够。
如果还是每次都要我主动打开控制台看，那么它仍然只是一个：
“故障发生以后用来查数据的工具”。
更实用的方式应该是：
正常状态
→ 不打扰
接近资源上限
→ 自动提醒
真正接近耗尽
→ 升级报警等级
因此我继续配置了 4 条报警：
CPU
内存
磁盘
公网流出带宽
十一、公网带宽报警：60% / 80% / 95%
第一条配置的是：
公网流出带宽使用率过高
监控指标：
(ECS) IP 维度公网流出带宽使用率
并选择当前 ECS 的公网 IP 作为维度。
我最终设置了三档：
Info
连续 5 分钟
平均值 >= 60%
Warn
连续 5 分钟
平均值 >= 80%
Critical
连续 3 分钟
平均值 >= 95%
我的考虑是：
60%
→ 开始关注
80%
→ 已经明显接近公网带宽上限
95%
→ 基本可以认为公网出口正在跑满
正常状态目前只有约 5%～20%，因此 60% 作为第一档不会太容易产生噪声。
十二、CPU 报警：70% / 85% / 95%
第二条是：
CPU 使用率过高
阈值：
Info：
>= 70%
持续 5 分钟
Warn：
>= 85%
持续 5 分钟
Critical：
>= 95%
持续 3 分钟
这条对我来说其实是最重要的。
因为今天真正造成 WordPress 502 的资源瓶颈就是 CPU。
当时已经出现：
CPU idle = 0%
PHP-FPM Worker 全部高负载
Load ≈ 9
如果当时已经有这条报警规则，那么在 WordPress 后台真正出现 502 之前，我应该就能收到提醒。
十三、内存报警：80% / 90% / 95%
第三条：
内存使用率过高
正常状态下当前内存使用率约：
44%
所以阈值设置为：
Info：
>= 80%
持续 5 分钟
Warn：
>= 90%
持续 5 分钟
Critical：
>= 95%
持续 3 分钟
之所以没有从 70% 就开始报警，是因为 Linux 会主动利用空闲内存做缓存。
看到：
内存用了 70%
并不意味着马上有问题。
因此对于这台 WordPress ECS：
80% 再开始关注更合理。
十四、磁盘报警：80% / 90% / 95%
第四条：
磁盘使用率过高
监控对象选择系统盘：
/dev/vda1
/dev/vda1 磁盘空间报警。阈值同样是：
Info：
>= 80%
持续 5 分钟
Warn：
>= 90%
持续 5 分钟
Critical：
>= 95%
持续 3 分钟
磁盘和 CPU 不一样。
磁盘达到 80% 时，即使网站暂时完全正常，也已经值得开始处理。
因为 WordPress 服务器还会不断产生：
- Nginx 日志
- PHP 日志
- WordPress 缓存
- 临时文件
- 插件文件
- 上传文件
- 系统日志
如果长期维持在 90% 以上，再发生一次日志暴增或者缓存重建，很容易迅速逼近 100%。
十五、最终只保留 4 条基础报警
全部创建完成以后，当前报警规则为：
| 资源 | Info | Warn | Critical |
|---|---|---|---|
| CPU | ≥70% 持续5分钟 | ≥85% 持续5分钟 | ≥95% 持续3分钟 |
| 内存 | ≥80% 持续5分钟 | ≥90% 持续5分钟 | ≥95% 持续3分钟 |
| 磁盘 | ≥80% 持续5分钟 | ≥90% 持续5分钟 | ≥95% 持续3分钟 |
| 公网流出带宽 | ≥60% 持续5分钟 | ≥80% 持续5分钟 | ≥95% 持续3分钟 |
我暂时没有继续配置：
Load
Redis
IOPS
TCP 连接数
网络包
错误包
PHP-FPM Worker
并不是这些指标没价值。
而是我现在更希望：
报警体系简单、明确、低噪声。
真正值得第一时间通知我的，就是：
CPU
内存
磁盘
公网带宽
这四项。
十六、报警沉默周期统一设置为 60 分钟
每一条报警规则都设置：
通道沉默周期：
60 分钟
而不是 24 小时。
这样：
第一次触发
→ 立即通知
异常持续存在
→ 60 分钟内避免重复轰炸
60 分钟后仍未恢复
→ 可以再次提醒
对于生产服务器来说，我觉得这个节奏比较合适。
如果设置成 24 小时：
上午触发一次
↓
下午再次严重异常
↓
可能仍处于沉默窗口
这个间隔就太长了。
十七、监控时间设置为全天
服务器显然不是只在工作时间运行。
所以生效时间统一设置为：
00:00 ～ 23:59
并勾选：
周一
周二
周三
周四
周五
周六
周日
也就是：
7 × 24 小时持续监控。
十八、报警联系人也确认了一遍
最后我还打开：
云账号报警联系人
确认当前已经绑定：
手机通知：已配置
邮箱通知：已配置
不同报警等级的通知强度也不同。
大致可以理解成：
Info
→ 邮件
Warn
→ 短信 + 邮件
Critical
→ 电话 + 短信 + 邮件
这正好符合我的需求。
普通异常不需要电话轰炸。
真正接近服务器资源耗尽时，Critical 再用更强的通知方式提醒。
十九、这套监控也解决了“要不要升级服务器”的问题
今天一开始，我其实一直在考虑：
1C2G
→
2C4G
甚至还在考虑：
2 Mbps
→
5 Mbps
原因很简单。
发生 502 时看到的是：
CPU 100%
Load 9+
PHP-FPM queue 510 / 511
直觉当然是：
服务器配置不够了。
但后面的排查证明：
异常 Sogou UA 被 EdgeOne 拦截
↓
PHP-FPM queue 归零
↓
CPU idle 一度恢复到 97%
↓
WordPress 后台恢复正常
现在云监控恢复以后，又看到正常状态：
CPU：
约 20%～30%
内存：
约 44%
磁盘：
约 51%
公网流出带宽：
通常只有上限的 5%～20%
因此现在已经没有理由立即升级。
更合理的方式变成：
继续使用 1C2G + 2 Mbps
↓
Agent 持续采集
↓
报警自动提醒
↓
积累 7 天 / 14 天 / 30 天基线
↓
再根据真实长期数据决定是否升级
这比凭一次 502 就立刻花钱升级可靠得多。
二十、这次真正补上的，是“提前发现问题”的能力
上一篇故障排查解决的是：
为什么 WordPress 会突然 502。
这一次做的事情则更像是在补基础设施。
以前：
网站异常
↓
我发现
↓
登录 SSH
↓
执行命令
↓
抓现场
↓
分析
现在则多了一层：
ECS
↓
Agent 4.0.0
↓
云监控持续采集
↓
CPU / 内存 / Load / 磁盘 / 网络
↓
超过阈值
↓
主动报警
↓
再进入服务器深入排查
这两者的区别其实很大。
监控并不能自动解决故障。
但它可以让我更早知道：
故障正在形成。
比如今天这种情况，如果 CPU 已经连续 5 分钟超过 85%，我就应该开始关注。
如果进一步达到：
95% 持续 3 分钟
那么甚至不用等 WordPress 真正出现 502，我就已经知道：
源站正在逼近极限。
二十一、最终状态
这次最终完成了：
云监控 Agent
2.1.56 已停止
↓
升级
↓
4.0.0 运行中
恢复监控：
CPU
内存
Load
磁盘
磁盘 IO
网络
公网带宽
网络连接
并配置四条报警：
CPU 使用率过高
内存使用率过高
磁盘使用率过高
公网流出带宽使用率过高
与此同时：
ECS：
继续保持 1C2G
公网带宽：
继续保持 2 Mbps
暂时都不升级。
下一步不再继续调整服务器，而是：
让云监控持续积累正常业务基线。
等 7 天甚至更长时间以后，再去看：
CPU 长期峰值
内存长期占用
Load
磁盘增长速度
公网带宽使用率
如果这些数据长期都很健康，那么现有配置就继续使用。
如果真正开始频繁触发 Warn 或 Critical，再讨论升级。
相比“感觉服务器是不是不够用了”，这种方式显然更加可靠。
这一次，从 502 故障一路排查下来，最终得到的不只是一次故障修复。
更重要的是：
服务器终于从“出了问题以后再查”，变成了“问题接近发生时就能提前告诉我”。
Linux 服务器运维、部署与线上故障排查
如果你的网站或后端服务部署在 Linux 服务器上，遇到访问异常、Nginx 配置问题、MySQL / Redis 异常、Docker 服务不可用、磁盘占满、CPU / 内存过高等问题，可以联系我做一次远程排查。
适合以下场景：
✅ 网站打不开或访问不稳定
✅ Nginx / PHP-FPM 配置异常
✅ MySQL / Redis 性能或连接问题
✅ Docker 服务部署与维护
✅ 服务器迁移与环境配置
✅ CPU / 内存 / 磁盘异常排查
服务内容：
✅ Linux 环境检查
✅ 网站部署与迁移
✅ Nginx / PHP-FPM / MySQL / Redis 排查
✅ Docker 配置与维护
✅ 服务器性能分析
✅ 长期远程运维支持
如需咨询，请联系我，并注明：Linux 运维咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复