Josh Suereth
Josh Suereth
@SuperQ I believe what happens today in Prometheus (with client lirbaries) is the process itself crashes (eventually) on high cardanility. OTEL deemed this unacceptable, which is why we suppress/limit cardinality...
@bboreham @bwplotka I do like what you're suggesting with setting the value of labels to "oveflow". It's not entirely feasible in OTEL because we don't have string labels, we have...
@dashpole This doesn't fix the fact that they will consume memory storing metrics client side.
This is now ready for review/merge
@carlosalberto I think we need to release the proto directory....
I think we should clarify this in the specification. Given we're moving from Explicit Bucket => Exponential histograms, we think it is reasonable that users would ALSO be able to...
The limit is intended to be against the amount of *in memory storage* you have. Given that, I believe the filtering *MUST* be done on your hot-path. The intention is...
> @jsuereth did you mean "Given that, I believe the [limiting] MUST be done on your hot-path"? Not necessarily the filtering, right? Yep! Limiting MUST be on hot path, you...
> If one implementation filters prior to the limiting and another filters afterwards they could produce different outputs. Is consistency here going to be an issue? I think regarding cardinality...
Another way to phrase it -> I think users, if given a choice, would prefer lower o11y overhead per-language over perfect consistency.