Non-numeric Gauges?

[Tyler Tolley]

I've been using the library for a while but I've never seen a use case for gauges to return a non-numeric type. Has anyone ever made use of the functionality? It seems like it adds some complexity to the library without much value. Would such use cases fit better as health checks? I'm currently working on a .net port of the library and I'm wondering if this is something worth "fixing" in that version.

[Marshall Pierce]

I never have either. Try only exposing numeric types and see how it goes; maybe we can ditch everything but int, long, and double for metrics 4. :)

> On Feb 22, 2016, at 7:51 AM, Tyler Tolley <thatto...@gmail.com> wrote:
>
> I've been using the library for a while but I've never seen a use case for gauges to return a non-numeric type. Has anyone ever made use of the functionality? It seems like it adds some complexity to the library without much value. Would such use cases fit better as health checks? I'm currently working on a .net port of the library and I'm wondering if this is something worth "fixing" in that version.
>

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

[Chris lohfink]

I placed a listener on database queries, and used stream-lib's stream summary to keep track of the 10 worst queries and 10 most frequently called. Then when debugging poor performance I look at the gauge to see a String[] of worst/most frequent DB queries.

Chris

I've been using the library for a while but I've never seen a use case for gauges to return a non-numeric type. Has anyone ever made use of the functionality? It seems like it adds some complexity to the library without much value. Would such use cases fit better as health checks? I'm currently working on a .net port of the library and I'm wondering if this is something worth "fixing" in that version.

--

[Marshall Pierce]

Interesting use of a Gauge — how are you accessing this data? Via JMX or some other way?

[Chris lohfink]

Jmx

[Marshall Pierce]

OK. I think this is a neat idea, and one that should be easy, but I’m not convinced that a Gauge<String[]> is a great conceptual fit with what a Gauge should be. It sounds like this is really just using Metrics as a convenient way to expose something via JMX. Thoughts?

[Tyler Tolley]

That is a creative way to use the gauge. To me it feels like it should be something different just because most reporters are ignoring non-numeric gauges. Perhaps healthcheck should be expanded to provide extra data beside just the result? Or maybe this is something else entirely. Just my two cents.

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/OVtTNhpQucU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to metrics-user...@googlegroups.com.

[Pete Robbins]

I've been using (mis-using?) some complex gauges which contain event data eg: Gauge<MyEventClass> The event contains related information that may not make sense as individual numeric guages. I'm using a reporter that is serializing Gauges to JSON which is good for my purposes but I'm sure other Reporters would just have to ignore my custom Gauge.

[Marshall Pierce]

I don’t think it’s too controversial that it makes sense for numeric gauges to participate in normal reporting as they currently do (e.g. queue depth over time). For the non-numeric gauges, it seems like there are two ways they are used:

- regular reporting of compound data
- ad-hoc queries into application state

The former seems hard to deal with in a generic way. How could both CSV and and JMX agree on how to represent a Gauge<ComplexObject>? If the common numeric case was represented by LongGauge, etc, then perhaps it would work out to say “Gauge<T> needs a custom reporter to do anything useful”.

The latter seems like it is (ab?)using Metrics to satisfy a need for simple ways to express stuff over JMX. Maybe this would be a good thing to write a separate library for. It’s not hard to abstract away much of the annoyance of manually wiring JMX.