moomindani commented on PR #16250: URL: https://github.com/apache/iceberg/pull/16250#issuecomment-5234643783
Pushed `1311c585a` — docs only, no behavior change. Added a "Cardinality limits" subsection under the attribute set. The reporter attaches `iceberg.table.name` by default, so the number of time series grows with the number of tables, and the [metrics SDK spec](https://opentelemetry.io/docs/specs/otel/metrics/sdk/) caps a metric stream at 2000 attribute combinations by default. Past that limit the SDK folds further measurements into a single `otel.metric.overflow=true` data point with the original attributes removed — totals stay correct while per-table breakdowns silently go incomplete, and nothing errors, so the degradation is easy to miss. The attribute-set section already suggested dropping `table-name` "in deployments with a very large number of tables" without saying what goes wrong or where the threshold sits. It now spells both out and notes that alerting on the overflow attribute is the only available signal. Raising the limit stays with the host application, consistent with the SDK lifecycle being owned there — the reporter doesn't touch it. This is the concern @vaquar raised on the dev@ thread, now with a concrete number attached. Prompted by [this OpenTelemetry blog post](https://opentelemetry.io/blog/2026/cardinality-limits-in-opentelemetry/) covering the same mechanism. @nastra all your review comments remain addressed; this only adds documentation on top. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
