A gauge metric with a "set" method

[Guy Marom]

Hello everyone,

I'm part of the team in my company that's in charge of metrics and we recently implemented a library to wrap Dropwizard metrics for consumption in Prometheus as their Java client is problematic.

A lot of our developers expressed the need of a "SettableGauge" - a gauge with a "set" method.

I was wondering if any consideration was ever given to this and if there are drawbacks to this method?

One drawback we are aware of is that it is confusing. Since Prometheus "pulls" the values from the process it's entirely possible that not all the values that were set to the gauge will later show in Prometheus' database.

Thanks for the information,

Guy

[Guy Marom]

By the way, if anyone's interested we've open-sources our library and it can be found on github.

[Ryan Kennedy]

Gauge is an interface, so there shouldn't be anything preventing you from creating a SettableGauge today, right?

https://github.com/dropwizard/metrics/blob/3.2-development/metrics-core/src/main/java/com/codahale/metrics/Gauge.java

There's a CachedGauge today, which isn't all that dissimilar from a SettableGauge:

https://github.com/dropwizard/metrics/blob/3.2-development/metrics-core/src/main/java/com/codahale/metrics/CachedGauge.java

You mentioned that a problem with Prometheus is that it pulls from the process. That would seem to indicate to me that you want a poll-able Gauge, instead of a settable one. So I'm slightly confused about which use case is problematic.

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

[Guy Marom]

Gauge is an interface, so there shouldn't be anything preventing you from creating a SettableGauge today, right?

You are right of course.

That would seem to indicate to me that you want a poll-able Gauge, instead of a settable one

The gauge is "pollable" since it has a getValue() method. Indeed when Prometheus samples my processes I am polling all gauges for their values and return them to Prometheus in the required format.

The reason I wrote this is because we were uncomfortable with implementing the SettableGauge. It seemed all users who wanted this were somehow abusing the metric system (I can't really explain why) and I was wondering if your design ever considered it and came into some conclusions I should consider.

I guess not :)

Thanks,

Guy

To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

[Ryan Kennedy]

This is probably a conversation better suited to the metrics-user group as folks there will have the most up-to-date context.

Reading back through the thread starter, this point you made stood out. "Since Prometheus "pulls" the values from the process it's entirely possible that not all the values that were set to the gauge will later show in Prometheus' database." Is this ultimately the issue you're concerned about? That some changes in the gauge's value may go unnoticed by Prometheus due to the polling frequency? If so, I'm not certain there's much you're going to be able to do about that. Gauge is, ultimately, a point in time reading. This is why counters, timers, meters, and histograms exist…they're able to assimilate ongoing activity and expose that in a way that allows most of the necessary information to be conveyed regardless of the polling interval.

You could reduce the polling interval, but then you'll be trading system resources for data freshness. So assess how valuable it is to "see" every tick of the gauge. You could also try something a bit unconventional and implement a gauge that stores the last N changes/last N <timeunit> of changes, but then you're putting the responsibility of making sense of that on whatever polls the metric (like building soft counters/timers/meters/histograms out of gauges).

I don't feel like there's anything necessarily wrong with a SettableGauge. I've certainly done the equivalent of it in the past, with my code updating some member variable and the getValue() implementation reading from that. But even that doesn't solve the problem of missing updates in your metrics system of choice. Maybe I don't understand what this implementation of SettableGauge would look like. Is it simply this or something more complex?

class SettableGauge<T> implements Gauge<T> {

    private AtomicReference<T> value;

    public T getValue() {

        return value.get();

    }

    public void setValue(T value) {

        this.value.set(value);

    }

}

Ryan

To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-de...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "dropwizard-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dropwizard-dev/Mjdpo-xO4Ss/unsubscribe.

To unsubscribe from this group and all its topics, send an email to dropwizard-de...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "dropwizard-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-de...@googlegroups.com.