.*: update prometheus client, remove deprecated InstrumentHandler and InstrumentHandlerFunc methods

[kakkoyun]

Updates prometheus/client_golang. Remove usages of deprecated methods by introducing wrapper methods which mimics behaviour the same behaviour using new APIs.

Fixes #1304

Changes

• Updates prometheus/client_golang.
• Removes usages of prometheus.InstrumentHandler and prometheus. InstrumentHandlerFunc
• Introduces extprom/NewInstrumentedHandler and extprom/NewInstrumentedHandlerFunc.
• Removes http_request_duration_microseconds (Summary).
• Adds http_request_duration_seconds (Histogram).

New metrics:

# HELP http_request_duration_seconds Tracks the latencies for HTTP requests.
# TYPE http_request_duration_seconds histogram
# HELP http_request_size_bytes Tracks the size of HTTP requests.
# TYPE http_request_size_bytes summary
# HELP http_requests_total Tracks the number of HTTP requests.
# TYPE http_requests_total counter
# HELP http_response_size_bytes Tracks the size of HTTP responses.
# TYPE http_response_size_bytes summary

Old metrics:

# HELP http_request_duration_microseconds The HTTP request latencies in microseconds.
# TYPE http_request_duration_microseconds summary
# HELP http_request_size_bytes The HTTP request sizes in bytes.
# TYPE http_request_size_bytes summary
# HELP http_requests_total Total number of HTTP requests made.
# TYPE http_requests_total counter
# HELP http_response_size_bytes The HTTP response sizes in bytes.
# TYPE http_response_size_bytes summary

Verification

By using make test and manual testing against query API, it seems like previous behaviour kept intact.

[bwplotka]

Awesome, thanks for this! 👍

Looking good from the first glance, but will review closer soon.

Can we add CHANGELOG for metric changes we are making here?

[metalmatze]

Very nice job @kakkoyun 🎉

[bwplotka]

Some suggestions but overall awesome. Let me know what are your thoughts (:

[bwplotka]

Also not sure of Instrumentor name.. Isn't Middleware bit better and clearer? Not a blocker, might be by personal preference, up to you.

[GiedriusS]

Maybe I am wrong but I think that if we would name these middlewares then there might be more confusion in the future when (if) we will switch to using Cortex's middlewares for caching.

[kakkoyun]

I wasn't also sure about Instrumentor name, it's not even an actual word. I'm ok to use Middleware.

@GiedriusS Since it will be under a particular namespace with package structure, maybe it won't create any confusion. What do you think?

[kakkoyun]

@bwplotka How about InstrumentationMiddleware? It'll go like extpromhttp.NewInstrumentationMiddleware, NewInstrumentationMiddleware().NewHandler() etc.

[bwplotka]

Maybe I am wrong but I think that if we would name these middlewares then there might be more confusion in the future when (if) we will switch to using Cortex's middlewares for caching.

Well that will be exactly the same middleware isn't it?

 ... handler http.Handler) http.HandlerFunc { ...

[brancz]

InstrumentationMiddleware sounds good to me. As the package and context are revolving around http, I think it's pretty clear, and doesn't cause confusion.

[bwplotka]

Thanks! LGTM