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
Collector already registered that provides name: cache_request_total #2399
Comments
Could you provide a minimal sample project to reproduce this issue so we can more easily investigate and ensure any fix is working properly for your use case? I tried to reproduce this but was not able. class GitHub2399Test {
MeterRegistry registry = new PrometheusMeterRegistry(PrometheusConfig.DEFAULT);
@Test
void collectorAlreadyRegistered() {
registry.counter("cache.request", "type", "MISS").count();
registry.counter("cache.request", "type", "HIT").count();
}
} |
I have similar case when I try to register the same name timer with different tags. the reason is because when 2 same name timer with different tags, the PrometheusMeterRegistry::applyToCollector() will remove the record from the collectorMap. But it won't unregister it from the registry. So 3rd time will always encounter the exception |
We are having the same issue and looking for a work around or fix. Here is class that we used to reproduce the issue. public class MeterTest {
private PrometheusMeterRegistry registry;
public MeterTest()
{
registry = new PrometheusMeterRegistry(PrometheusConfig.DEFAULT);
Metrics.addRegistry(registry);
}
public static void main(String[] args) {
MeterTest mt = new MeterTest();
mt.addMeters();
mt.scrape();
}
public void addMeters()
{
String metricsPrefix = "metertest";
Timer.Sample ts1 = Timer.start(Metrics.globalRegistry);
ts1.stop(Metrics.globalRegistry.timer(
String.format("%s.%s", metricsPrefix, "service.request"),
"service", "PrsnlService",
"method", "read",
"result", "Success"));
Timer.Sample ts2 = Timer.start(Metrics.globalRegistry);
ts2.stop(Metrics.globalRegistry.timer(
String.format("%s.%s", metricsPrefix, "service.request"),
"service", "SurgeonRegistryService",
"method", "query",
"result", "Success"));
Timer.Sample ts3 = Timer.start(Metrics.globalRegistry);
ts3.stop(Metrics.globalRegistry.timer(
String.format("%s.%s", metricsPrefix, "service.request"),
"service", "SurgeonService",
"method", "read",
"inRegistry", "True",
"result", "Success"));
Timer.Sample ts4 = Timer.start(Metrics.globalRegistry);
ts4.stop(Metrics.globalRegistry.timer(
String.format("%s.%s", metricsPrefix, "service.request"),
"service", "ScheduledSurgeryService",
"method", "queryByNPI",
"douUser", "True",
"result", "Success"));
Timer.Sample ts5 = Timer.start(Metrics.globalRegistry);
ts5.stop(Metrics.globalRegistry.timer(
String.format("%s.%s", metricsPrefix, "service.request"),
"service", "SurgerySurveyService",
"method", "queryByCaseNumber",
"result", "Success"));
}
public void scrape()
{
System.out.println(registry.scrape());
}
} This is the stacktrace:
|
This should be "fixed" in the latest snapshots for |
Hi, how can I use the |
I have an application which registers a timer with the same tags (keys are the same, values differ), which is triggering this bug under load. So it doesn't seem to only appear when the tags are different. I'll try to come up with a reproducer. |
Ah, it could be that the application has some |
We are also seeing this issue. Stack trace in our case is as follows:
Notes about our case: we are using tags as well, and because the tag values are variable, we are always calling DistributionSummary.builder(id)
.publishPercentiles(DEFAULT_PERCENTILES)
.publishPercentileHistogram()
.tags(tags)
.register(meterRegistry)
.record(length); We could save the builder up to just before the The interesting thing about this is that I can't reproduce locally in a simple test, even when varying the tags. It only occurs in a more interesting environment (such as production). Can the root cause be due to Spring Boot reloading the context? (As a Spring Boot newbie, I'm probably way off here, but I read some things about how Spring sometimes automatically reloads the context? 🤷 Maybe something that is causing the micrometer cache to be cleared, but not the native prometheus library cache [prometheus simpleclient] to be cleared?) |
See the section of the README titled "Snapshot builds". In short, add a maven snapshot repository with url https://repo.spring.io/libs-snapshot to your build.
Builder instances are mutable, so that would not likely be what you want. Calling register should be fine, since its behavior is to create (if not already existing) or retrieve (if already existing) the meter. |
@shakuzen we faced the original issue and we are now using version |
It's not really a new issue. Metrics with the same name but a different set of labels has never shown up in the prometheus scrape endpoint due to the limitation imposed by the Prometheus Java client that we depend on. Not throwing the exception by default was only getting rid of the error; not changing the limitation. We recently reopened #877 to explore the possibility of working around that limitation, but just noting again, it's a limitation that has always existed for the Prometheus registry. |
@shakuzen thanks for the information, we are able to work around the issue with this info. Thanks! |
Had problem using |
Running micrometer 1.6.2. I just initialized a bunch of counters with different labels.
In constructor of application,
The text was updated successfully, but these errors were encountered: