On Sat, 4 Apr 2020 at 00:27, Victor Watkins <[email protected]> wrote:
> Hi! This question is about best practices for testing applications that > use client_golang to instrument with custom metrics and avoiding the > dreaded "duplicate metrics collector registration attempted". > > Let's say I have an HTTP handler for an app that keeps a counter. The > counter can be page hits, orders submitted, whatever. Let's say my handler, > a struct with ServeHTTP attached, refers to this counter either as a > package level variable or as a a struct member. I've seen the same behavior > either way. Suppose I keep the typical patterns: use promauto, register my > Collectors in New, or register my collectors at package initialization. > > When I put my handler under test, I typically create a handler per test. > This causes me to bump into "duplicate metrics collector registration > attempted". > That will only happen if you register in New, the other options will only ever register once. Accordingly you shouldn't register package-level variables in New. > Some ways I have worked around this are to create a single httptest.Server > with my handler in TestMain, or attach a RegisterMetrics to defer collector > registration where I'm wiring up my dependencies (often main's main func) > and just not register the metrics under test. The former makes it harder to > inject mocks with different behaviors, the latter makes it hard to test my > metrics. > > So, the questions are: > 1) What are some good ways to deal with metric registration under test? > 2) Is testing metrics a typical practice, or do you just trust them? In > the contrived example, it may be reasonably safe to just trust it, but I'm > confident we have seen those cases where there is some tricky behavior > around our metrics and we want to be sure we have it right. > It depends, would you unittest a log line providing the same information? It's it's only a log line for debugging probably not, if it's a a first class feature for the given code (e.g. rpcs handled for a rpc library) then you should test it. > 3) When testing metrics, such as in an exporter concept where that is in > fact the key behavior, is it typical to test the metrics endpoint with an > http call (say, with httptest.Server) or do you look at the values held by > the collectors? > Whatever is easiest, going all the way to http sounds a bit much to me though. -- Brian Brazil www.robustperception.io -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/CAHJKeLqeV-VQKrOFJkW2-ct8vSx65sTMbj9JwAUQuc8XJdef8g%40mail.gmail.com.
