A metric with the name xxx has already been registered
See original GitHub issueI believe the intention here https://github.com/siimon/prom-client/blob/c63689bbbb6a0395ce9d806b0cc17cf5d380f4a8/lib/registry.js#L83 was to use something like !_.isEqual
so consecutive creation of the same metric won’t fail (behave like a getOrCreate
).
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:9
Top Results From Across the Web
Registry Counter panic: duplicate metrics collector registration ...
Better: Use custom registry to have explicit control on what is registered ... Name: "xxx", Help: "The total number of processed events", ...
Read more >prometheus - Go Packages
Package prometheus is the core instrumentation package. It provides metrics primitives to instrument code for monitoring.
Read more >prometheus - The Go Programming Language - GitHub Pages
NewExpvarCollector returns a newly allocated expvar Collector that still has to be registered with a Prometheus registry. An expvar Collector collects metrics ......
Read more >KB32359: Attribute or metric names are missing from reports ...
CAUSE: The column alias for the affected was changed to an empty string (" "). ACTION: To correct the issue: From the report...
Read more >Adding additional metrics to Dropwizard - Stack Overflow
Every metric in that instance of the jvm is exposed via JMX. You can also register metric reporters that will do thing liks...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks for the clear explanation @trboltom! Based on that and the other comments in this thread, it sounds like we should keep the current behavior. I think that encourages clean code logic also (e.g. ensure your services are singletons).
Note that this is easy to handle upstream:
(Side note: this design decision frustrates me. I’ve made typos before in collection names and this behavior makes the error hard to find.)
@zbjornson You are correct that registering two different metrics with the same name has to end with an error. We wanted to do this change in order to suppress this error in case you try to register the same metric twice.
This can happen for example when you are adding new collectors in the constructor of some service and then inject this service without making it a singleton. This will result in constructor of this service being called multiple times during one request, which will end up in try to register one metric multiple times.
This is an error/mistake on the developers side and so it’s probably not good enough reason to implement this. I thought that it could be a good idea to ignore second attempt and just dont do any action. However as I am writing this comment it has become clear to me that we probably really dont want to implement it in this way. Its probably better to keep this check there as is and just let developer know that something is not alright.
If you agree I will close that PR, but this issue is not mine and so someone else will have to close it if all agree