Attribute limits not supported in Metrics

[jtmalinowski]

What are you trying to achieve?

As open-telemetry/opentelemetry-specification#1130 is nearing completion we're aiming to support Attribute limits in all models, which have Attributes. However, Metrics cause additional difficulties, because truncation and/or deletion of their attributes could affect their identity, which requires further discussion.

Additional context.

Some notes from a comment on open-telemetry/opentelemetry-specification#1130:

• Should attribute truncation in metrics be considered user configuration error? Relevant to open-telemetry/semantic-conventions#1163
• Metric Identity overlap post-truncation
• Which attributes should be kept for metrics? (@reyang has this hint-api idea for preserving important attributes)
• Should attribute truncation happen before or after View attribute truncation?

And some more ideas from another comment in open-telemetry/opentelemetry-specification#1130:

• Limiting attribute length can lead to duplicate (identity) metric points being exported, especially for verbose labels where the tailing-end of the label contains the important part. E.g. `"processor"; "com.java.really.long.package.name.FooBar". In this case, we should be encouraging users to use the shortest, readable metric attributes, but is otherwise considered an error state.
• Limiting the # of attributes could lead to duplicate metric time series being emitted from the SDK. Here we should inform users that this is considered a configuration error, and we expect them to provide a high enough value for metric streams or provide View aggregation to limit high attribute-count metrics. We can leave the error reporting + mechanism for this TBD, but we need to call out this is a very real problem in the current (stable) data model.

[jtmalinowski]

I'm happy to own this one and drive the discussion, unless someone working on Metrics would like to own it.

[manolama]

HI! Starting to look into supporting OTel but I'm worried about this idea of truncating data. The limits make absolute sense and being configurable is great. But to avoid user confusion, avoid the duplicated identity issue, and the problems of how to truncate UTF-8 from https://github.com/open-telemetry/opentelemetry-specification/issues/504, wouldn't it be better to drop the errant data and notify the user? E.g. have the APIs return a response code, 0 for good, non-zero for a data error. Then use the built-in SDK telemetry to track the errors. I think truncation will lead to a world of hurt.

[reyang]

Two updates:

• I've sent a PR to give some guidance/suggestion on how to handle memory limits open-telemetry/opentelemetry-specification#1966.
• I think the Metrics SDK spec will not define the exact behavior in the initial Stable release (so the SDK authors can have flexibility), as we called out here.