unbridled-41 opened a new pull request, #5419:
URL: https://github.com/apache/rocketmq-dashboard/pull/5419
## Problem / Evidence
The bundled `RocketMQJVMCpuHigh` rule
(`server/src/main/resources/alerts/rocketmq-jvm-gc-cpu-high.yaml:9`, generated
by `server/scripts/gen_alert_rule_yaml.py:82`) advertises:
> "The broker spends more than 30% of CPU time in GC pauses."
but its expression is
```
rate(jvm_gc_pause_seconds_count[5m]) *
avg(rate(jvm_gc_pause_seconds_sum[5m])) > 0.3
```
`rate(jvm_gc_pause_seconds_sum[5m])` is already the share of time spent in
GC (seconds of pause per second of wall clock, a dimensionless ratio).
Multiplying it by `rate(jvm_gc_pause_seconds_count[5m])` (GC events/second)
produces "pauses/second × pause-time share", which has no "30% of the time"
meaning.
The rule is therefore wrong in both directions:
| Scenario | count rate | sum rate (time in GC) | LHS | Fires? | Should
fire? |
|---|---|---|---|---|---|
| 20 young GCs/s × 2 ms | 20 | 0.04 (4%) | 0.8 | yes | no |
| 1 GC/s × 250 ms | 1 | 0.25 (25%) | 0.25 | no | no (correct by luck) |
| 1 GC/s × 400 ms | 1 | 0.40 (40%) | 0.40 | yes | yes |
Any broker that collects frequently with short pauses (the common
young-generation pattern) fires the alert while spending almost no time in GC —
and the same "30%" threshold silently means something different at every
collection rate.
These assets are user-facing: `AlertRuleAssetService.loadDefaultRules()`
feeds `AlertService.exportPrometheusRulesYaml()`, so a user with no custom
rules exports exactly this expression into Prometheus, and the same YAML is
served by `GET /api/alert-rules/assets/{name}` and `/{name}/export`.
## Root cause / Fix
The pause-count rate was multiplied into a value that is already the ratio
the annotation describes. Fix: compare the pause-time ratio directly, summed
over the GC series:
```
sum(rate(jvm_gc_pause_seconds_sum[5m])) > 0.3
```
Changed in the generator, the checked-in asset, and the dev-mode mirror in
`web/src/mock/alertRuleAssets.ts`.
## Priority & scoring
PRIORITY 64 = 影响 22 (a shipped default alert rule mis-grades a core
broker-health signal, both false positives and missed pressure) + 波及 10 (one
asset + generator + mock, but it is exported as the default rule set) + 可复现 20
(deterministic arithmetic on the expression) + 维护价值 12 (correctness of a
monitoring asset).
FIX_CONFIDENCE 92: a one-line expression change with a regression test that
pins the contract; no API, schema or behavioural surface beyond the rule text.
## Tests
```
cd server && mvn -o test -Dtest=AlertRuleAssetServiceTest
```
- Red before the fix: `expected: <sum(rate(jvm_gc_pause_seconds_sum[5m])) >
0.3> but was: <rate(jvm_gc_pause_seconds_count[5m]) *
avg(rate(jvm_gc_pause_seconds_sum[5m])) > 0.3>`
- Green after: `Tests run: 12, Failures: 0, Errors: 0, Skipped: 0`
- Regenerating all 23 assets with `server/scripts/gen_alert_rule_yaml.py`
reproduces the checked-in directory byte for byte (`diff -rq` clean).
- `mvn -o checkstyle:check` passes.
## Risk
Low. The expression change is confined to one bundled asset; rule name,
group, severity, duration and annotations are untouched, so fingerprints/state
keys that reference the rule are unaffected.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
