Splitting out latency with a success/failure label is also not recommended as a) if you have only successes or only failures, your queries break and b) users tend to create graphs of only success latency and miss all those slow failing requests. Separate success and failure metrics are better, and also easier to work with in PromQL.
Thanks for the suggestions Brian! promhttp package contains even more nice things like in flight requests. Maybe we should explicitly say ok in docs that InstrumentHandler is deprecated in favor of promhttp types? I don’t mind making a PR in docs
Nice article.
Beware that
InstrumentHandleris deprecated, and the functions in https://godoc.org/github.com/prometheus/client_golang/prometheus/promhttp are the recommend replacement.Splitting out latency with a success/failure label is also not recommended as a) if you have only successes or only failures, your queries break and b) users tend to create graphs of only success latency and miss all those slow failing requests. Separate success and failure metrics are better, and also easier to work with in PromQL.
Thanks for the suggestions Brian! promhttp package contains even more nice things like in flight requests. Maybe we should explicitly say ok in docs that InstrumentHandler is deprecated in favor of promhttp types? I don’t mind making a PR in docs
That’s already mentioned in the docs: https://godoc.org/github.com/prometheus/client_golang/prometheus#InstrumentHandler
That’s an excellent article! Thanks for posting it!
Definitely can have the DevOps tag!