Open rtrox opened 10 months ago
Dropping this here for now. This will technically be a breaking change, but given how new the bazarr collector is, I doubt we have more than a few folks graphing it. I'd like to get this in somewhat quickly to keep it that way.
Marking help wanted
as (again) I don't actually have a bazarr instance to test with, but I'm off this week, so if this isn't picked up quickly, I'll spin up a test instance later this week and make this change.
I run Bazaar (every exporter you implement actually) and am willing to help however I can, but I'm unable to glean your ask from the messaging here. If you still desire a test platform, let me know how I can help.
Details
What steps did you take and what happened:
While working on some other things, I noticed this -- right now we're exporting counts of episodes/movies by
score
-- like other *arrs,score
is a percentage indication of certainty, and at least in bazarr, it has 2 decimals of precision. This means cardinality for this label could theoretically hit 10k.Graphing this metric is likely to be done via pie chart / bar distribution, which means a quantile a) bounds cardinality to bucket count, and b) is actually a bit better representation of this type of value anyway.
Additional Information
Prometheus Quantiles: https://prometheus.io/docs/practices/histograms/ MustNewConstHistogram: https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#MustNewConstHistogram Example Usage: https://github.com/prometheus/client_golang/blob/main/prometheus/examples_test.go#L440-L446 (note: bucket labels are an inclusive upper bound)
Reference
https://github.com/onedr0p/exportarr/blob/e42774b10cd3ad7cbdd2d99cfe177d39841da648/internal/arr/collector/bazarr.go#L335-L348