pilichoumao opened a new issue, #7277: URL: https://github.com/apache/rocketmq-dashboard/issues/7277
### Before Creating the Bug Report - [x] Searched existing issues and PRs for `jvmMemoryHeapUsed`, heap/native and heap/catalog. - [x] This concerns Studio's capability declaration and runtime-info collector. - [x] Reproduced against `rocketmq-studio` commit `127c47b06a268cc74224d5f34c56ec7c36ac0d55`. ### Studio Version `rocketmq-studio` at `127c47b06a268cc74224d5f34c56ec7c36ac0d55`, source-level collector reproduction. ### Runtime Environment Linux ECS, JDK 21. The reproduction compiles and executes unmodified RocketMQ 5.5.0 StoreStatsService and feeds its runtime map into the current Studio ApacheRocketMqClusterMetricsCollector through mocked MQAdminExt/RuntimeAdminClientResolver. This is not a full Broker RPC or deployed cluster test. No MySQL/browser is involved. ### Connected RocketMQ Cluster The source examined is stock Apache RocketMQ `rocketmq-all-5.5.0`. Custom broker plugins can add runtime-info fields and are explicitly considered below. Other versions have not been exhaustively tested. ### Describe the Bug The Apache cluster native alert catalog offers `broker.jvm.heap.usage_ratio` and accepts rules for it. The collector requires `jvmMemoryHeapUsed` and `jvmMemoryHeapMax`, but the examined stock 5.5.0 runtime-info path does not publish those fields. Existing positive collector tests supply them artificially. Consequently an ordinary heap threshold rule can be created without a stock source for its values; the collector returns UNAVAILABLE/null. An explicit unavailable-condition rule may still fire, so this is not a claim that every heap-related rule can never fire. ### Steps to Reproduce 1. Read stock 5.5.0 [`StoreStatsService.getRuntimeInfo`](https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/store/src/main/java/org/apache/rocketmq/store/StoreStatsService.java#L497), [`DefaultMessageStore.getRuntimeInfo`](https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/store/src/main/java/org/apache/rocketmq/store/DefaultMessageStore.java#L1248), and [`AdminBrokerProcessor.prepareRuntimeInfo`](https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/broker/src/main/java/org/apache/rocketmq/broker/processor/AdminBrokerProcessor.java#L2651). None of these standard layers supplies the heap keys. The last layer also supports broker plugin fields. 2. Execute the unmodified StoreStatsService after one sampling initialization, then inspect its runtime map: both heap keys are absent. 3. Pass the map to Studio's actual Apache collector. In the reproduction, disk/queue fields that the other two source layers supply are added explicitly as controls: disk ratio `0.75`, queue size/capacity `250/1000`. 4. Observe heap UNAVAILABLE/null while disk and queue ratios are `0.75` and `0.25`. 5. Query the native catalog for an Apache instance and validate a heap rule: the option is offered and the rule accepted. 6. Add plugin-style heap fields `768/1024`: the same collector correctly produces `0.75`, demonstrating why extension compatibility matters. ### What Did You Expect to See? The catalog should describe the metric sources available to the selected instance, and distinguish permanently unsupported sources from temporary sampling failure. Operators should know when broker heap needs an extension or another metric source. ### What Did You See Instead? All Apache instances receive the same heap option even though the examined stock runtime-info source has no matching fields. Missing fields are treated as unavailable samples. ### Additional Context: proposed design for discussion I would like maintainer feedback before implementing a catalog/validation policy change, as required by CONTRIBUTING.md. #6527 is a related capability-filtering precedent for a different provider/metric, not approval for removing this option. **Preferred direction to discuss:** make the availability of the broker heap source explicit. Stock runtime-info should not advertise a measurable heap threshold by default; preserve the existing collector for plugin-supplied fields. Decide whether support is declared in instance configuration or represented as a catalog capability before adding a new API/configuration field. Absence in one polling cycle must not downgrade a known supported source permanently. Compatibility decisions that need agreement: | Case | Proposed invariant | | --- | --- | | Stock instance, no heap source | Do not offer a misleading new heap threshold rule; explain the missing source. | | Extension that publishes both heap fields | Keep ratio collection and permit rules when its source is explicitly supported. | | Supported source temporarily unreachable/missing data | Preserve unavailable handling and existing alert state; do not infer permanent unsupported status. | | Existing stored heap rules | Keep them readable/exportable and preserve IDs, configuration, enabled flags and alert state. No automatic deletion or migration. Decide explicitly how unchanged-metric edits/test/import should behave. | | Existing custom extension rules | Preserve evaluation; a blanket Apache catalog deletion must not silently invalidate them. | | Cloud instances and other native metrics | Retain current provider contracts. In particular stock 5.5.0 does supply send-thread-pool queue capacity. | Related #4519/#4521 and #5478/#5449 fixed false recovery when runtime data is missing. This proposal must preserve those unavailable samples and reconciliation safeguards; it concerns whether a stock source supports the metric in the first place. #3844 also uses synthetic heap fields for collector tests. **Alternative:** retain heap as a selectable capability and implement a real remote JVM source (for example an explicitly configured external JVM metrics source). This has broader configuration, authentication and failure-handling requirements. Studio's own JVM heap must never substitute for the remote broker's heap. A one-line removal from `CLUSTER_APACHE` was explored only as a policy prototype. It rejects new rules while retaining collector parsing, but it is **not a complete fix**: `validate` is shared by create/update/test/import, so it also affects old-rule editing. The current catalog tests explicitly require heap to be offered. They must be changed only after the intended contract is agreed. Proposed implementation acceptance checks after consensus: - Stock-source fixture with absent heap fields, plugin fixture with 768/1024 -> 0.75, and transient-unavailability fixture. - Catalog/API and UI follow the agreed source capability, with Chinese and English text where needed. - Create/update/test/import/export coverage for both new and existing heap rules, including the unchanged-metric edit case. - Existing state and custom-source evaluation remain intact; disk/queue and cloud controls remain green. - Current-source clean compilation, related backend tests and production packaging; any new UI receives frontend tests/build. ### Are You Willing to Submit a Pull Request? - [x] Yes, after maintainers agree on source capability and existing-rule compatibility. -- 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]
