[xu-xiaofei]

Describe what this PR does / why we need it

The system-rule CPU check (SystemRuleManager#checkSystem) consumes the raw per-second processCpuUsage snapshot computed in SystemStatusListener with no smoothing and no bounds.

In containerized environments (cgroup CPU quota + -XX:+UseContainerSupport), we observed that this raw snapshot can exceed the physical bound of 1.0 by large factors: in production, threshold-exceeding snapshots reached 28.75 (i.e. 2875% CPU), and 80.1% of the threshold-exceeding samples were above 1.0, while the real process CPU usage (micrometer process.cpu.usage, which reads the same getProcessCpuLoad() family of metrics) stayed at 0.00-0.31 at those exact seconds.

Since the container's cgroup quota caps the whole process at availableProcessors CPU-seconds per second, any value outside [0.0, 1.0] is physically impossible. A single anomalous sample is consumed directly by checkSystem() and blocks all inbound requests for that second (HTTP 429), producing large false-positive rate-limiting bursts: in our production this caused tens of thousands of spurious 429s across several services during traffic peaks.

Production data and analysis: #3669

Does this pull request fix one issue?

Fixes #3669

Describe how you did it

In SystemStatusListener:

1. Clamp the raw process CPU usage to [0.0, 1.0] - with the cgroup quota capping the process at availableProcessors CPU-seconds/second, values outside this range can only be measurement anomalies.
2. Smooth the clamped value with a sliding window over the latest 10 samples (~10 seconds at the 1s tick) before publishing it via getCpuUsage(); a single anomalous sample is diluted to at most 1/10 of the window. We measured a ~10-second read granularity of getProcessCpuTime() in the affected environments (threshold-exceeding values sit strictly on a 1.25 = 10,000ms/1,000ms/8-cores grid), so a 10-sample window covers a full read cycle.
3. Guard against unusable samples (negative deltas / unreadable processCpuTime) by keeping the last smoothed value.
4. Keep the existing Math.max(processCpuUsage, systemCpuUsage) semantics of currentCpuUsage unchanged.

No changes to rules, slots, configuration or the checkSystem logic. The public contract (getCpuUsage() returning the CPU usage) is unchanged - only the value becomes bounded and smoothed. Worst-case behavior change: detection of a real sustained overload is delayed by at most a couple of ticks (covered by unit tests).

Describe how to verify it

• New unit tests SystemStatusListenerTest (6 cases): clamping of an impossible 28.75 sample, dilution of a single spike (0.4,0.4,0.4,0.4 + spike -> 0.52), negative-delta keeps last value, sustained overload (0.9 x10) still triggers, bounded ramp-up delay, partial-window averaging.
• Reproduction of the incident shape: feed one sample with delta(processCpuTime) = 230,000ms on a 1s tick with 8 cores (raw = 28.75) between normal 0.4 samples - before this patch the snapshot blocks all traffic for that second; after this patch the smoothed value stays at 0.52.

Special notes for reviews

• The window size (10) was chosen to cover the observed ~10s read granularity; it is a constant and easy to tune.
• The threading model is unchanged: run() is still invoked by the single-threaded scheduler in SystemRuleManager; currentCpuUsage remains volatile.
• If maintainers prefer, the clamping alone (one line) already removes the physically-impossible values; the sliding window additionally protects against GC/JIT burst seconds that stay within [0,1] but still exceed typical thresholds for a single tick.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
36 out of 37 committers have signed the CLA.

✅ kirklin
✅ EzrealOf
✅ sczyh30
✅ xiaozzzi
✅ wenshao
✅ garroshh
✅ pandaapo
✅ wuwen5
✅ quguai
✅ JosephZhang3
✅ wilsonwu
✅ frank-zsy
✅ Yan1025
✅ shichaoyuan
✅ robberphex
✅ saaivenk
✅ LearningGp
✅ clara0
✅ DepUpdater
✅ cdfive
✅ Linzyoo
✅ marmot-z
✅ mawen12
✅ dowenliu-xyz
✅ 24kpure
✅ karl-sy
✅ ruansheng8
✅ ylnxwlp
✅ hermya
✅ xierunzi
✅ XenoAmess
✅ manojks1999
✅ Layau-code
✅ gaoyf
✅ z521598
✅ uuuyuqi
❌ Xu

---

Xu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}