[Task] Separate the code for indicator monitoring

[songxiaosheng]

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.

[walklown]

Please add some details. Do you want to separate the code of the dubbo-metrics module?

[songxiaosheng]

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?

[walklown]

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.

[songxiaosheng]

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.

[ShenFeng312]

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.

[walklown]

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'.

1. The current task aims to reverse the dependence between metrics and dubbo-core.
2. Spring Boot’s ease of use is based on many basic codes, not just dependency injection. In fact Dubbo also implemented its own BeanFactory, but didn't think it was a good idea to complicate it.
3. It is indeed a good suggestion to use combination instead of inheritance. I hope that subsequent PRs can do better.
4. The management of metric collection/exposure and metric service lifecycle are currently separated, and the indicator design can still be improved. I will try to improve the indicator collection part in the PR of the current task, and I will look forward to specific opinions. Suggestions for design improvements in other parts can be made in 'Refector Metric export' tasks.
5. 'integrate and merge the monitoring of both Spring Boot Actuator and Dubbo in the same application' I think it as indicator visualization, which is a completely different topic. It is recommended to discuss it in a separate issue.