* Clarify exemplarAdd by renaming to addWithExemplar
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Documenting addWithExemplar
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* Also rename exemplarObserve to follow the same pattern
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
Signed-off-by: Dave Henderson <dhenderson@gmail.com>
* fix assorted oddities found by golangci-lint
Signed-off-by: Christoph Mewes <christoph@kubermatic.com>
* permanently enable the linters
Signed-off-by: Christoph Mewes <christoph@kubermatic.com>
* post-rebase blues
Signed-off-by: Christoph Mewes <christoph@kubermatic.com>
* Check validity of method and code label values
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
* Use more flexibly functional option pattern for configuration
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
* Update documentation
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
* Simplify
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
* Fix inconsistent method naming
Signed-off-by: Kemal Akkoyun <kakkoyun@gmail.com>
Without this fix, the `InstrumentHandler...` middlewares get locked in
an endless loop in case of an invalid Collector, eating all the memory.
Signed-off-by: beorn7 <beorn@grafana.com>
As it turned out, it's not that esay to guess "common" combination of
interface upgrades. So I decided to just implement all 32 possible
combination of interface upgrades. (Only 16 with Go 1.7 and earlier.)
Clearly, this calls for code generation. But right now, we still need
to find out what's the best form of the code. For later additions,
implementing code generation might be useful.
Note that newDelegator is called for each HTTP request. Thus, this
commit aims to make the upgrade selection quick. (After the type
checks, it's just directly accessing an element in a slice.)
re