Hello every one,
it seems that once in a while FusionAuth is returning duplicate metrics but reporting different values. Our Prometheus stack is deployed on k8s and we get this error:

{"caller":"scrape.go:1820","component":"scrape manager","level":"warn","msg":"Error on ingesting samples with different value but same timestamp","num_dropped":8,"scrape_pool":"serviceMonitor/dev/fusionauth-dev/0","target":"http://xxx.xxx.xxx.244:9011/api/prometheus/metrics","ts":"2025-12-08T09:34:49.026Z"}
{"caller":"scrape.go:1820","component":"scrape manager","level":"warn","msg":"Error on ingesting samples with different value but same timestamp","num_dropped":8,"scrape_pool":"serviceMonitor/dev/fusionauth-dev/0","target":"http://xxx.xxx.xxx.244:9011/api/prometheus/metrics","ts":"2025-12-08T09:35:19.020Z"}
{"caller":"scrape.go:1820","component":"scrape manager","level":"warn","msg":"Error on ingesting samples with different value but same timestamp","num_dropped":8,"scrape_pool":"serviceMonitor/dev/fusionauth-dev/0","target":"http://xxx.xxx.xxx.244:9011/api/prometheus/metrics","ts":"2025-12-08T09:35:49.029Z"}

This error happens randomly and it doesn't tell which metrics are duplicates.
Is anyone facing the issue in subject while scraping FusionAuth metrics with Prometheus?
Thank you for any hint
have a lovely day
_
Fabio

hello @mark-robustelli
thank you very much to take the time to look into this.
I've also asked the LLM and got a similar answer,
as you suggested the Database_primary_pool_Usage indicates "how much of the primary database connection pool is currently in use"
but this cannot be the number of connections because the metrics reported are often way above the max value of Database_primary_pool_MaxConnections which is set to 20, so for example a reported value of 45 or 100 makes no sense.
For this I suspect that the quantile metric reported is the time consumed by the application in milliseconds, but this is just my best guess and I could be completely off.
Also this metric: Database_primary_pool_Usage_count sems to be a monotonic counter, is this the size of the sample used to calculate the percentiles? If this never reset as long as the application is running, how large is the sample pool used to generate the quantiles?
Sadly the page mentioned only helps you setting up Prometheus scraping, it's not a real reference for exported metrics.
It would be very helpful to have a reference page for this metrics.
The Prometheus HELP that comes along with the metrics is not telling the unit either, but it's a generic summary:

# HELP Database_primary_pool_Usage Generated from Dropwizard metric import (metric=Database-primary.pool.Usage, type=com.codahale.metrics.Histogram)
# TYPE Database_primary_pool_Usage summary

Same problem with other similar metrics:

# HELP Database_primary_pool_Wait Generated from Dropwizard metric import (metric=Database-primary.pool.Wait, type=com.codahale.metrics.Timer)
# TYPE Database_primary_pool_Wait summary
Database_primary_pool_Wait{quantile="0.5",} 3.7480000000000004E-6
Database_primary_pool_Wait{quantile="0.75",} 0.001360131
Database_primary_pool_Wait{quantile="0.95",} 0.0014736360000000002
Database_primary_pool_Wait{quantile="0.98",} 0.001568443
Database_primary_pool_Wait{quantile="0.99",} 0.0016282640000000001
Database_primary_pool_Wait{quantile="0.999",} 0.0023040590000000002
Database_primary_pool_Wait_count 1419.0

Sorry for this rant, but it seems to be hard to have some meningful metrics in Grafana.
My kindest regards
_
Fabio