[DISCUSS] MetricRegistryListener bounded on implemetation

[Ralph Su]

Hi,

Current metrics-core support metrics are great. But i got question when i try to add my own metric implementation to MetricRegistry.

In dropwizard 3.1.0, MetricRegistry could have MetricRegistryListener added, which define the event trigger for different metric. But this interface is now bounded to the implemented metric in notifyListenerOfAddedMetric like below, which mean when i try to add some Metric implementation, i had to be bound to Gauge, Histogram, Meter, Timer, all this are concrete classes except Gauge. Means i can not simply programming according to Metric interface and nowhere to add listener for such metric. (There are already some Listeners there)

private void notifyListenerOfAddedMetric(MetricRegistryListener listener, Metric metric, String name) {
        if (metric instanceof Gauge) {
            listener.onGaugeAdded(name, (Gauge<?>) metric);
        } else if (metric instanceof Counter) {
            listener.onCounterAdded(name, (Counter) metric);
        } else if (metric instanceof Histogram) {
            listener.onHistogramAdded(name, (Histogram) metric);
        } else if (metric instanceof Meter) {
            listener.onMeterAdded(name, (Meter) metric);
        } else if (metric instanceof Timer) {
            listener.onTimerAdded(name, (Timer) metric);
        } else {
            throw new IllegalArgumentException("Unknown metric type: " + metric.getClass());
        }
    }

So i have to either
a. rewrite the my-own MetricRegistry and listeners, which make messy codes
b. Inherit from one of the above class, which is not feasible. The only choice is the Gauge

I'm thinking metric-core 2.x style of com.yammer.metrics.core.MetricsRegistryListener make more sense here.

My case is trying to build metrics not sliding time window but time-batch style(e.g. exactly count of request every given interval).

Thanks,
Ralph

[Marshall Pierce]

I believe custom metrics are slated for metrics 4.

Regarding your goal of non-sliding window (shall we call them epoch-based?) metrics — I agree, that is a very useful way of recording things. I hope we can make metrics 4 more compatible with this type of measurement. As a stopgap for metrics 3, I ended up adding a special reservoir implementation to https://bitbucket.org/marshallpierce/hdrhistogram-metrics-reservoir that resets every time you ask it for a snapshot. Not great, but it gets the job done if you need that behavior.

> --
> You received this message because you are subscribed to the Google Groups "metrics-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to metrics-user...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Liangfei.Su]

Thanks for the pointing. I did have an implementation yet, but will looking the hrhistogram, it looks great. Regarding the metrics-core question, seems we have to waiting for metrics 4...

You received this message because you are subscribed to a topic in the Google Groups "metrics-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/metrics-user/2OBQvDc-l2M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to metrics-user...@googlegroups.com.