unbridled-41 opened a new issue, #5455:
URL: https://github.com/apache/rocketmq-dashboard/issues/5455
### Studio Version
branch: `rocketmq-studio`
git commit id: `6a68042f` (the revision this was verified against; the
branch is based on it)
deployed as: built from source (unit test)
### Runtime Environment
Not environment-specific: the defect is in a bundled Prometheus rule file,
and the verification is a unit test
(`server/src/test/java/org/apache/rocketmq/studio/ops/alert/AlertRuleAssetServiceTest.java`)
that reads the asset from the classpath.
### Connected RocketMQ Cluster
Not cluster-specific.
### Describe the Bug
The bundled `RocketMQJVMCpuHigh` alert rule
(`server/src/main/resources/alerts/rocketmq-jvm-gc-cpu-high.yaml:9`, generated
by `server/scripts/gen_alert_rule_yaml.py`) 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 wall-clock time
spent in GC (seconds of pause per second), so multiplying it by the pause-count
rate produces "GC pauses per second scaled by the pause-time share" — a
quantity with no "30% of the time" meaning. The same threshold therefore means
something different at every collection rate.
This asset is user-facing: `AlertRuleAssetService.loadDefaultRules()` feeds
`AlertService.exportPrometheusRulesYaml()`, so a user with no custom business
rules exports exactly this expression into Prometheus; the raw YAML is also
served by `GET /api/alert-rules/assets/{name}` and `/{name}/export`.
### Steps to Reproduce
1. Read `server/src/main/resources/alerts/rocketmq-jvm-gc-cpu-high.yaml` (or
export the default rule set through the alert rules API).
2. Evaluate the left-hand side for a broker collecting 20 times per second
with 2 ms pauses: `20 * 0.04 = 0.8 > 0.3`, although only 4% of the time is
spent in GC, so the rule fires.
3. Evaluate it for 1 collection per second with a 250 ms pause: `1 * 0.25 =
0.25 < 0.3`, so it stays silent.
### What Did You Expect to See?
The rule fires when the share of time spent in GC pauses exceeds 30%, as its
own annotation states, independently of how often collections happen.
### What Did You See Instead?
The threshold compares GC frequency scaled by the pause share, firing for
frequent short pauses that spend almost no time in GC and staying silent for
other combinations.
### Evidence
- Asset: `server/src/main/resources/alerts/rocketmq-jvm-gc-cpu-high.yaml:9`;
generator: `server/scripts/gen_alert_rule_yaml.py` (`RULES` entry for
`rocketmq-jvm-gc-cpu-high`).
- Verification: `cd server && mvn -o test -Dtest=AlertRuleAssetServiceTest`
— the added case `gcCpuAlertShouldCompareTheGcTimeRatio` fails against the old
expression (`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>`) and passes with the corrected one; regenerating all 23 assets
reproduces the checked-in directory byte for byte.
### Impact
Anyone who deploys the exported default rule set gets a GC alert that
mis-grades both directions: false positives on brokers with frequent short
young collections, and no alert for slower pauses of the same total duration.
### Acceptance Criteria
- The bundled rule compares the summed pause-time share against 0.3.
- The generator and the checked-in asset stay byte-identical.
- A regression test pins the expression.
**Corresponding PR:** #5419
--
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]
