In the previous troubleshooting session, my WordPress blog suffered severe server resource exhaustion due to an abnormally high volume of requests carrying the Sogou web spider/4.0 User-Agent.
At the peak of the incident:
Load Average ≈ 9
CPU idle = 0%
PHP-FPM Socket queue = 510 / 511
A large number of requests returned 499 / 502
WordPress admin dashboard intermittent 502
Ultimately, I used EdgeOne to block them directly at the edge nodes:
User-Agent: *Sogou*
→ Block
The server recovered quickly:
PHP-FPM Socket:
510 / 511
→
0 / 511
CPU idle:
0%
→
up to 97%
Local backend test:
5 consecutive HTTP 200
Although the issue was resolved, this incident exposed another problem:
My ECS lacked an intuitive server monitoring system capable of retaining historical data and triggering proactive alerts.
If CPU utilization maxes out, memory anomalies occur, disk space runs low, or public bandwidth approaches its limit in the future, I do not want to wait until WordPress returns a 502 and then hastily SSH into the server to capture the scene.
Therefore, after handling the abnormal Sogou traffic, I went ahead and built up the host monitoring and alerting system for my Alibaba Cloud ECS.
1. Why I Decided to Build Up Cloud Monitoring After This 502
Resolving this incident ultimately relied on real-time checks on the server.
For example:
uptime
vmstat
free -h
ps
ss
These commands helped me confirm:
CPU had no idle capacity left
PHP-FPM was the primary CPU consumer
Memory was not exhausted
The FastCGI wait queue was nearing its limit
This data was certainly very useful.
The problem, however, is that they mostly represent:
Manually logging into the server to capture the scene after a failure has already occurred.
If I had not happened to notice the 502 on the backend, or if the server load had only been abnormal briefly before recovering on its own, much of the scene data could have already been lost.
A more reasonable approach would be:
Server continuously collects metrics
↓
Saves historical trends
↓
Exceeds threshold
↓
Proactive alert
↓
Then decide whether SSH deep troubleshooting is needed
Therefore, after resolving this incident, I did not immediately upgrade the ECS. Instead, I prioritized setting up monitoring.
2. ECS Has Built-in Basic Monitoring, but the Information Is Incomplete
Actually, Alibaba Cloud ECS itself already provides some basic monitoring.
For example:
- CPU
- Public network traffic
- Public network bandwidth
- Network packets
- Some instance-level metrics
Initially, I also checked the public network bandwidth for the last 7 days in the ECS console.
Based on the data at the time, outbound public bandwidth was mostly only:
About 200～300 Kbit/s
Occasionally reaching:
About 500～800 Kbit/s
While the purchased fixed public bandwidth for the server is:
2 Mbps
Thus, I could already make a preliminary judgment:
Public bandwidth was not the bottleneck for this 502, and there is currently no immediate need to upgrade from 2 Mbps to 5 Mbps.
However, I also noticed that some monitoring panels still showed:
No data
Especially for:
- Memory usage
- System Load
- Disk usage
- Operating system network interfaces
- Processes, etc.
This requires a monitoring Agent inside the server.
3. I Briefly Entered Cloud Monitoring 2.0, but Found It Too Heavy for a Personal Blog
After clicking “Install Cloud Monitoring Plugin” on the ECS page, I initially landed on Alibaba Cloud’s relevant Cloud Monitoring page.
Alibaba Cloud now has a new suite:
Cloud Monitoring 2.0
Upon entering “Access Center → Cloud Server ECS”, I found that it further guided me to activate Enterprise Cloud Monitoring, Prometheus, and other capabilities.
For large systems, multi-server setups, containers, Prometheus, log correlation, and unified observability systems, this solution is certainly more complete.
But my needs are actually very simple:
A single WordPress ECS
↓
Check CPU
Check memory
Check Load
Check disk
Check public bandwidth
↓
Send me an alert on anomaly
If I were to bring in the entire Enterprise Cloud Monitoring, Prometheus, and log collection system just for these basic needs, it would be somewhat too complex for me.
Therefore, I did not proceed with the Cloud Monitoring 2.0 onboarding process.
4. The Traditional “Host Monitoring” Entry Is Actually Still There
Later, I went back to the traditional Cloud Monitoring page.
On the left side, you can still see:
Cloud Resource Monitoring
→ Host Monitoring
Upon entering, I immediately spotted a key issue.
It wasn’t that my ECS had never had an Agent installed.
The page showed:
Agent version: 2.1.56
Agent status: Stopped
At the same time:
CPU: No data
Memory usage: No data
Disk: No data
This also explained why many OS-level metrics had been missing data all along:
The Agent existed, but had long since stopped running.
5. Instead of Restoring the Old Agent, I Upgraded Directly
The page provided:
Batch install or upgrade plugin
So I selected the current ECS and prepared to upgrade.
Alibaba Cloud then popped up a prompt:
This installation (upgrade) will install the LoongCollector collector.
It also reminded me that if the server had previously used iLogtail, the upgrade might involve Logtail/LoongCollector compatibility and configuration migration.
My server did not rely on the old iLogtail for critical business log collection, so after confirming, I proceeded directly with the upgrade.
The entire process did not modify WordPress, Nginx, PHP-FPM, or Redis, nor did it require rebooting the ECS.
6. Agent Upgraded from 2.1.56 to 4.0.0
After the upgrade completed, I returned to “Host Monitoring”:
Agent version: 4.0.0
Agent status: Running
The metrics that had been showing “No data” immediately started populating:
CPU: 25.2%
Memory usage: 44.02%
Disk usage: 50.96%
This result also made me more certain:
The lack of OS monitoring previously wasn’t because the ECS itself didn’t support it, but because the old Agent had stopped working.
7. Finally Able to View CPU, Memory, and System Load Directly
I entered:
Host Monitoring
→ Monitoring Charts
→ OS Monitoring
And was able to see:
- CPU usage
- Memory usage
- System average load
- Disk usage
- Disk read/write
- IOPS
When monitoring was just restored, the data was roughly:
CPU:
About 20%～30%
Memory:
About 44%
Disk:
About 51%
The system Load still showed the lingering effects of the previous incident.
For example:
1-minute Load
Dropped the fastest
5-minute Load
Dropped next
15-minute Load
Dropped the slowest
This was completely consistent with my earlier observations in the server terminal.
8. Why “1 Hour” Has Data, but “1 Day” Temporarily Does Not
Right after upgrading the Agent, there was another phenomenon that could easily cause confusion.
Viewing:
1 hour
showed the monitoring curves.
But switching to:
1 day
many OS metrics still showed:
No data
The reason is actually quite simple.
The old Agent had stopped running, and the new 4.0.0 Agent had just started collecting.
Therefore:
Before 15:43
No Agent data
After 15:43
Continuous collection started
Cloud Monitoring cannot magically backfill OS data like memory, Load, and disk that was never collected in the past.
So I just needed to let the Agent keep running.
After a few hours, a day, or a few days:
6 hours
12 hours
1 day
3 days
7 days
These time ranges would naturally accumulate complete monitoring curves.
9. Network Monitoring Is Also Much More Complete Than Before
Continuing to switch to:
Network Monitoring
I could see:
- Network interface bandwidth
- Network interface inbound packets
- Network interface error packets
- Network connections
- VPC public bandwidth
- Public outbound bandwidth usage
The most valuable metric for me was:
(ECS) IP dimension public outbound bandwidth usage
Because my server purchased:
2 Mbps fixed public bandwidth
This percentage directly answers:
Whether 2 Mbps is enough.
Looking at the curve after restoration:
Most of the time:
About 5%～20%
Some peaks:
About 20%～35%
Highest:
Approaching 40%
That is to say, even calculated against the 2 Mbps limit:
40% ≈ 0.8 Mbps
20% ≈ 0.4 Mbps
10% ≈ 0.2 Mbps
There is still a clear margin before truly maxing out the 2 Mbps currently.
Therefore, at least for now:
There is no need to upgrade public bandwidth.
10. Since Monitoring Was Restored, I Took the Opportunity to Set Up Alerts Too
Monitoring alone is not enough.
If I still have to manually open the console to check it every time, then it remains merely a:
“tool used to look up data after a failure occurs”.
A more practical approach should be:
Normal state
→ No disturbance
Approaching resource limit
→ Automatic reminder
Truly nearing exhaustion
→ Escalate alert level
Therefore, I proceeded to configure 4 alerts:
CPU
Memory
Disk
Public outbound bandwidth
11. Public Bandwidth Alerts: 60% / 80% / 95%
The first one configured was:
Public outbound bandwidth usage too high
Monitoring metric:
(ECS) IP dimension public outbound bandwidth usage
And I selected the current ECS’s public IP as the dimension.
I ultimately set three tiers:
Info
Consecutive 5 minutes
Average >= 60%
Warn
Consecutive 5 minutes
Average >= 80%
Critical
Consecutive 3 minutes
Average >= 95%
My reasoning was:
60%
→ Start paying attention
80%
→ Clearly approaching the public bandwidth limit
95%
→ Can basically assume the public outbound is maxed out
Normal state is currently only about 5%～20%, so 60% as the first tier won’t easily generate noise.
12. CPU Alerts: 70% / 85% / 95%
The second one was:
CPU usage too high
Thresholds:
Info:
>= 70%
for 5 minutes
Warn:
>= 85%
for 5 minutes
Critical:
>= 95%
for 3 minutes
This one is actually the most important to me.
Because the resource bottleneck that actually caused the WordPress 502 today was the CPU.
At that time, the following had already occurred:
CPU idle = 0%
PHP-FPM Workers all under high load
Load ≈ 9
If this alert rule had been in place then, I should have received a reminder before the WordPress backend actually started returning 502.
13. Memory Alerts: 80% / 90% / 95%
The third one:
Memory usage too high
Under normal conditions, current memory usage is about:
44%
So the thresholds were set to:
Info:
>= 80%
for 5 minutes
Warn:
>= 90%
for 5 minutes
Critical:
>= 95%
for 3 minutes
The reason I didn’t start alerting at 70% is that Linux proactively uses free memory for caching.
Seeing:
Memory at 70%
does not mean there is an immediate problem.
Therefore, for this WordPress ECS:
It is more reasonable to start paying attention at 80%.
14. Disk Alerts: 80% / 90% / 95%
The fourth one:
Disk usage too high
I selected the system disk as the monitoring target:
/dev/vda1
/dev/vda1 disk space alert.The thresholds are likewise:
Info:
>= 80%
for 5 minutes
Warn:
>= 90%
for 5 minutes
Critical:
>= 95%
for 3 minutes
Disk is different from CPU.
When disk usage reaches 80%, even if the website is temporarily perfectly fine, it is already worth starting to address.
Because the WordPress server will continuously generate:
- Nginx logs
- PHP logs
- WordPress cache
- Temporary files
- Plugin files
- Uploaded files
- System logs
If it stays above 90% long-term, another surge in logs or a cache rebuild could easily push it rapidly toward 100%.
15. Ultimately Keeping Only 4 Basic Alerts
After creating them all, the current alert rules are:
| Resource | Info | Warn | Critical |
|---|---|---|---|
| CPU | ≥70% for 5 minutes | ≥85% for 5 minutes | ≥95% for 3 minutes |
| Memory | ≥80% for 5 minutes | ≥90% for 5 minutes | ≥95% for 3 minutes |
| Disk | ≥80% for 5 minutes | ≥90% for 5 minutes | ≥95% for 3 minutes |
| Public outbound bandwidth | ≥60% for 5 minutes | ≥80% for 5 minutes | ≥95% for 3 minutes |
I have temporarily not configured:
Load
Redis
IOPS
TCP connections
Network packets
Error packets
PHP-FPM Workers
It’s not that these metrics lack value.
Rather, I currently prefer:
An alerting system that is simple, clear, and low-noise.
What truly warrants notifying me immediately is:
CPU
Memory
Disk
Public bandwidth
These four items.
16. Alert Silence Period Unified to 60 Minutes
Each alert rule is set to:
Channel silence period:
60 minutes
Instead of 24 hours.
This way:
First trigger
→ Immediate notification
Anomaly persists
→ Avoid repeated bombardment within 60 minutes
Still not recovered after 60 minutes
→ Can remind again
For a production server, I feel this rhythm is more appropriate.
If set to 24 hours:
Triggered once in the morning
↓
Another severe anomaly in the afternoon
↓
Might still be within the silence window
This interval is too long.
17. Monitoring Time Set to All Day
Servers obviously do not run only during business hours.
So the effective time is uniformly set to:
00:00 ～ 23:59
And I checked:
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday
Which is:
7 × 24 hours continuous monitoring.
18. Alert Contacts Also Verified
Finally, I also opened:
Cloud account alert contacts
Confirmed that the following are currently bound:
Mobile notification: Configured
Email notification: Configured
The notification intensity varies for different alert levels.
It can be roughly understood as:
Info
→ Email
Warn
→ SMS + Email
Critical
→ Phone call + SMS + Email
This perfectly matches my needs.
Ordinary anomalies don’t need phone call bombardment.
When truly nearing server resource exhaustion, Critical uses a stronger notification method to remind me.
19. This Monitoring Setup Also Resolved the “Should I Upgrade the Server” Question
At the beginning of today, I was actually considering:
1C2G
→
2C4G
And even considering:
2 Mbps
→
5 Mbps
The reason is simple.
What I saw during the 502 was:
CPU 100%
Load 9+
PHP-FPM queue 510 / 511
The intuition was of course:
The server configuration is no longer sufficient.
But subsequent troubleshooting proved:
Abnormal Sogou UA blocked by EdgeOne
↓
PHP-FPM queue dropped to zero
↓
CPU idle recovered to 97% at one point
↓
WordPress backend returned to normal
Now that Cloud Monitoring is restored, I can also see the normal state:
CPU:
About 20%～30%
Memory:
About 44%
Disk:
About 51%
Public outbound bandwidth:
Usually only 5%～20% of the limit
Therefore, there is no reason to upgrade immediately now.
The more reasonable approach becomes:
Continue using 1C2G + 2 Mbps
↓
Agent continuously collects
↓
Alerts automatically remind
↓
Accumulate 7-day / 14-day / 30-day baselines
↓
Then decide whether to upgrade based on real long-term data
This is much more reliable than immediately spending money to upgrade based on a single 502.
20. What Was Truly Built Up This Time Is the Ability to “Discover Problems Early”
The previous troubleshooting resolved:
Why WordPress suddenly returned a 502.
What I did this time is more like patching up infrastructure.
Before:
Website anomaly
↓
I notice
↓
Log in via SSH
↓
Execute commands
↓
Capture the scene
↓
Analyze
Now there is an extra layer:
ECS
↓
Agent 4.0.0
↓
Cloud Monitoring continuously collects
↓
CPU / Memory / Load / Disk / Network
↓
Exceeds threshold
↓
Proactive alert
↓
Then log into the server for deep troubleshooting
The difference between the two is actually quite significant.
Monitoring cannot automatically resolve failures.
But it can let me know earlier:
A failure is forming.
For instance, in today’s situation, if the CPU had exceeded 85% for 5 consecutive minutes, I should have started paying attention.
If it further reached:
95% for 3 minutes
Then without even waiting for WordPress to actually return a 502, I would already know:
The origin server is approaching its limit.
21. Final Status
This time, I ultimately completed:
Cloud Monitoring Agent
2.1.56 stopped
↓
Upgraded
↓
4.0.0 running
Restored monitoring:
CPU
Memory
Load
Disk
Disk IO
Network
Public bandwidth
Network connections
And configured four alerts:
CPU usage too high
Memory usage too high
Disk usage too high
Public outbound bandwidth usage too high
At the same time:
ECS:
Continuing to maintain 1C2G
Public bandwidth:
Continuing to maintain 2 Mbps
Neither is being upgraded for now.
The next step is no longer to continue adjusting the server, but rather:
To let Cloud Monitoring continuously accumulate a normal business baseline.
After 7 days or even longer, I will then check:
Long-term CPU peaks
Long-term memory usage
Load
Disk growth rate
Public bandwidth usage
If this data remains healthy long-term, then I will continue using the current configuration.
If Warn or Critical alerts start triggering frequently, I will then consider an upgrade.
Compared to “feeling like the server might not be enough”, this approach is clearly more reliable.
This time, tracing down from the 502 incident, what I ultimately gained was more than just a single fault repair.
More importantly:
The server has finally transitioned from “investigating after a problem occurs” to “proactively notifying me as a problem approaches”.
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan
发表回复