+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
> >
>

Reply via email to