Expose `SummaryTimer` logic so clients can use it when calling `observe` about client_java HOT 4 CLOSED

I don't think we should presume that longs are ns, they could be ms if someone used currentTimeMillis. Both of those functions use different bases too (nanoTime isn't guaranteed to use the unix epoch). Thus a different approach is needed.

if responseStatusCode is a label, and its value isn't known until the request is finishing up, then the user has to fall back to using observe

It's generally recommended not to export latencies in this way, as there's a good chance a human will misinterpret the data.

from client_java.

It's generally recommended not to export latencies in this way, as there's a good chance a human will misinterpret the data.

Are you recommending against recording responseStatusCode as a label? I would definitely want to learn more about the recommended way if you have any links or examples.

I agree regarding treating longs as nanos could cause confusion. I prefer the Timer class to keep those details hidden. I've add #172 to demonstrate, since that was the core request of this issue.

from client_java.

Are you recommending against recording responseStatusCode as a label?

On latency metrics, yes.

I would definitely want to learn more about the recommended way if you have any links or examples.

One metric counting requests broken out by response code, another that's just latency.

from client_java.

Closed by #173

from client_java.