If a summary hasn't received any observations during its maxAge, its quantiles should be reported as NaN. about client_golang HOT 14 CLOSED

Yes, that is kind-of by design. Decay is only calculated upon observations. So if you do not observe anything, the current values will be 'frozen'. The next observation will completely flush anything (as it can even be seen in your graph, if looking closely).

It would be easy to also check for decay upon scrape. I'm just not sure what the better behavior is. A reset summary will return '0' for all quantiles, which is kind of wrong, too. 'NaN' would be more faithful, but probably confusing, too.

Arguably, no observations at all is a pathological state anyway. Perhaps returning the 'last known state' makes more sense...

Please let me know what you think.

@juliusv - do you have an opinion or historical state on this decision?

from client_golang.

It's a good point that this is a pathological state anyways. Except in circumstances where people take latencies of errors (but arguably you shouldn't do that unless errors are common, in which case you wouldn't have the problem).

0 is probably the worst option, as it has no basis in reality, but pretends to be "good". Keeping the last value could be ok. But NaN seems to be the most correct form, and I would prefer it.

Historically (at least with the original client), when a summary didn't get any observations yet, it just didn't export anything yet - no quantiles at all. That's probably not possible anymore with the new client library? I guess it would be similar in effect (but less explicit) than NaN.

from client_golang.

So you mean the metric should completely disappear if no observations happened in the decay period? Or only the quantiles? Either one should be easy to implement, we just have to be sure what's the most reasonable response.

from client_golang.

Biased by the old client, I was expecting at least the quantile metrics to disappear. I can't really comment on whether to omit the whole metric or just the quantiles.

from client_golang.

That's a good question. We currently never reset anything in the counters as long as any single sample comes in within MaxAge, right? I think for the counters it doesn't really make sense to reset them, as they were always meant as total counts/sums since instance start...

from client_golang.

Yeah, ..._count and ..._sum is never reset, and should probably not disappear. The quantiles could be left out. Just not sure if there are implications if that happens...

from client_golang.

Thinking through it, it should be fine. At least not worse than falsely reporting old quantiles.

from client_golang.

NaN is the best I think, that's what the equivalent for _sum/_count will return.

from client_golang.

@brian-brazil I don't understand. _sum/_count will never return NaN, will it? It's 0 if no observations have happened yet.

from client_golang.

Not sure about the latter part either, but NaN sounds good to me as well.

from client_golang.

Following http://prometheus.io/docs/practices/instrumentation/#avoid-missing-metrics, we definitely want to keep the quantiles. As we concluded 0 would be misleading, let's use NaN in this case. (Perhaps that would be something to add to the docs above, as 0 might not be useful in all cases?)

from client_golang.

I don't understand. _sum/_count will never return NaN, will it? It's 0 if no observations have happened yet.

When go you to get the latency 0/0 will return NaN (or is it +Inf in go?)

from client_golang.

Ah, that makes sense. Yes, 0/0 is NaN in Go.

from client_golang.

@brian-brazil I see, the '/' was actually a mathematical operator. My bad...

Yepp, all makes sense, title of this issue already adjusted.

from client_golang.