weaveworks / promrus Goto Github PK

It was reported in a Debian bug that TestRegisteringHookMultipleTimesShouldBeSafe fails when the tests are run on a system with only one or two CPUs, or alternatively on non-amd64 architectures with slower CPUs. The test failure output is at the end of this issue.

The cause appears to be that the metrics server started as a goroutine in httpServePrometheusMetrics() isn't fully ready to serve requests by the time the test code attempts to make a request. As a work around for the time being, I've introduced a quarter second sleep before returning from httpServePrometheusMetrics() (which is probably overkill) that fixes this test failure.

=== RUN   TestRegisteringHookMultipleTimesShouldBeSafe
    promrus_test.go:103: 
        	Error Trace:	/build/golang-github-weaveworks-promrus-1.2.0+git20210208.77c195c/_build/src/github.com/weaveworks/promrus/promrus_test.go:103
        	            				/build/golang-github-weaveworks-promrus-1.2.0+git20210208.77c195c/_build/src/github.com/weaveworks/promrus/promrus_test.go:29
        	Error:      	Expected nil, but got: &url.Error{Op:"Get", URL:"http://localhost:8080/metrics", Err:(*net.OpError)(0xc000025360)}
        	Test:       	TestRegisteringHookMultipleTimesShouldBeSafe
--- FAIL: TestRegisteringHookMultipleTimesShouldBeSafe (0.00s)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x8acf6a]

goroutine 8 [running]:
testing.tRunner.func1.2({0x9157c0, 0xdaaef0})
	/usr/lib/go-1.21/src/testing/testing.go:1545 +0x238
testing.tRunner.func1()
	/usr/lib/go-1.21/src/testing/testing.go:1548 +0x397
panic({0x9157c0?, 0xdaaef0?})
	/usr/lib/go-1.21/src/runtime/panic.go:914 +0x21f
github.com/weaveworks/promrus_test.httpGetMetrics(0x27?)
	/build/golang-github-weaveworks-promrus-1.2.0+git20210208.77c195c/_build/src/github.com/weaveworks/promrus/promrus_test.go:104 +0xca
github.com/weaveworks/promrus_test.TestRegisteringHookMultipleTimesShouldBeSafe(0x0?)
	/build/golang-github-weaveworks-promrus-1.2.0+git20210208.77c195c/_build/src/github.com/weaveworks/promrus/promrus_test.go:29 +0x98
testing.tRunner(0xc000106ea0, 0x9eb450)
	/usr/lib/go-1.21/src/testing/testing.go:1595 +0xff
created by testing.(*T).Run in goroutine 1
	/usr/lib/go-1.21/src/testing/testing.go:1648 +0x3ad
FAIL	github.com/weaveworks/promrus	0.023s

Typical usage is:

hook, err := promrus.NewPrometheusHook()
if err != nil {
    log.Fatalf("...", err) // or panic("...")
}

so it would make sense to wrap this up in a MustNewPrometheusHook function to keep things DRY.

log_messages should really be log_messages_total

https://prometheus.io/docs/practices/naming/

Note that an accumulating count has total as a suffix, in addition to the unit if applicable.

Hello, I'm just opening this issue to let you know, the next release of logrus (v1.2.0) will add a new trace level named Trace below Debug.
Here is the PR for reference sirupsen/logrus#844
You may want to take into account this new level.

Regarding this line
Set() was deprecated in July 2016 and removed in October 2016; please choose an alternative.

Can this support https://github.com/kubernetes/klog hooks

kubernetes/klog#167

If there is another library in your program trying to use a counter named log_messages, it's unpredictable which one wins.

Maybe some kind of namespacing in the name should be added, but from the Prometheus docs it seems that the AlreadyRegisteredError is designed for the case above.

When creating the same hook multiple times, the counter vector for the hook fails to be registered by Prometheus, which then fails with:

error duplicate metrics collector registration attempted

I might be better for promrus to:

• be able to safely to initialise the hook multiple times (in order to tolerate user errors and/or resets), OR
• be able to unregister the hook.

Initially raised by @bboreham here:

Please add to the documentation on this function that it cannot be called more than once, or bracket this section with a test to avoid causing an error duplicate metrics collector registration attempted (and adding multiple instances of the same hook below)

Would you accept a PR with a wrapper that allow configuring the supported log levels and doesn’t break the existing signature of NewPrometheusHook ?