Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4.1.11 and above throws error "tally.internal.counter_cardinality" is not a valid metric name #256

Open
nitrocode opened this issue Mar 31, 2024 · 6 comments

Comments

@nitrocode
Copy link

nitrocode commented Mar 31, 2024

error

I noticed we cannot upgrade past 4.1.10 because we get this error in our tests

panic: descriptor Desc{fqName: "tally.internal.counter_cardinality", help: "tally.internal.counter_cardinality gauge", constLabels: {}, variableLabels: [version host instance]} is invalid: "tally.internal.counter_cardinality" is not a valid metric name [recovered]

I noticed some changes in these tags that may be related

v4.1.10...v4.1.11

Is this panic an expected error or a regression?

references

@rbarabas
Copy link

Wondering about the same. Disabled cardinality metrics in NewRootScope() in the interim.

@TheCodingChameleon
Copy link

Setting the OmitCardinalityMetrics to true and false didn't remove this issue for my project, we have had to stay on v4.1.10

@ptxmac
Copy link

ptxmac commented May 7, 2024

Seeing this too, It looks like there's not great test coverage of the prometheus exporter

@ptxmac
Copy link

ptxmac commented May 7, 2024

There's a simple test that would have caught this issue: master...ptxmac:tally:test-prom

I used this with git bisect:

2498a0d is the first bad commit

@ptxmac
Copy link

ptxmac commented May 7, 2024

Found a workaround / correct way to initialize the root scope:

	tally.NewRootScope(tally.ScopeOptions{
		Prefix:          "prefix",
		Tags:            map[string]string{"env": "dev"},
		CachedReporter:  r,
		Separator:       prometheus.DefaultSeparator,
		SanitizeOptions: &prometheus.DefaultSanitizerOpts,
	}, 1*time.Second)

I guess that does technically make sense, but it's a shame that the default naming for cardinality metrics results in a panic if the correct options are not supplied.

If the default option results in a panic, then it's not really a good default option!

@TheCodingChameleon
Copy link

Is there any update on a fix being developed for this? It is stopping our projects from moving forward to the newer versions. As stated above a default that causes a panic isn't ideal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants