+1 for providing an easy way to integrate with existing popular monitoring/tracing systems
On Wed, Jun 13, 2018 at 8:41 AM, hty...@gmail.com <hty...@gmail.com> wrote: > easy integration to existing popular monitoring systems +1 > > I think this is very important since many companies already have their own > monitor system, it's better to provide an easy way to integrate with them > > On 2018/06/08 03:44:31, Huxing Zhang <hux...@apache.org> wrote: > > Hi All, > > > > I have took some time to look into the current implementation of Dubbo > > metrics, and I have some observations: > > > > * There is no uniform API for recording the metrics, current > > implementation is located separately in MonitorFilter and > > ActiveLimitFilter/ExecuteLimitFilter, and it is possible to have > > duplicate records if ActiveLimitFilter or ExecuteLimitFilter is turned > > on. > > * There is only total count and total response time for service/method > > rpc calls, no statistics within a specific interval, as well as > > response time in percentiles. > > * No thread pool related metrics > > * No uniform API for expose such metrics, e.g. via HTTP or JMX. This > > make is hard for external monitoring system to scrape data from Dubbo. > > Meanwhile, other features like circuit breaker will find it hard to > > utilize these metrics for judgement. > > > > Therefore, I am considering to refactor the current implement of > > metrics, with the following improvement: > > > > * Extract an uniform API for recording, and exposing the metrics > > * Add more metric types, e.g. interval base metrics, histograms, etc. > > * Provide easy integration to existing popular monitoring systems such > > as Prometheus > > > > Any thoughts? > > > > -- > > Best Regards！ > > Huxing > > >
