-
Notifications
You must be signed in to change notification settings - Fork 26.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Task] Separate the code for indicator monitoring #14016
Comments
Please add some details. Do you want to separate the code of the dubbo-metrics module? |
Yes, the current Dubbo application is forced to include the Dubbo metrics module internally. Is it possible to extract this module to reduce the coupling with the core code? |
Can it be assigned to me, thanks. |
okay You can take a look at this piece of code to see where there is room for optimization. |
Hello everyone, Through reading the source code of Spring Boot, I've observed that configuring monitoring exports seems to only require setting up XXXXMeterRegistry, such as InfluxMeterRegistry or OtlpMeterRegistry. In contrast, with Dubbo, our current initialization process involves setting up the complete AbstractMetricsReporter, which includes many complex implementations like addJvmMetrics, initCollectors, and even operations like registerDubboShutdownHook. I believe this approach is not quite reasonable. Instead, we should use composition over inheritance to clarify developers' tasks and implementation goals. This also aligns with the principle of least knowledge in design patterns. We should differentiate the management of metric collection/exposure and metric service lifecycle. Additionally, we need to consider how to integrate and merge the monitoring of both Spring Boot Actuator and Dubbo in the same application. It's worth noting that this may not require specific attention within Dubbo, as we should differentiate between Dubbo and Dubbo-SpringBoot. |
Noticed you made the same suggestion in 'Refector Metric export'.
|
The indicator monitoring code is separated. The Dubbo core warehouse is only responsible for initializing and automatically opening the corresponding functions based on whether the SPI exists.
The text was updated successfully, but these errors were encountered: