Apply [attribute] limits globally

[pellared]

What are you trying to achieve?

Currently part of the telemetry can have unbounded data like:

• resource attributes
• instrumentation scope attributes
• metric data attributes
• log record body
• attribute keys
• span names
• ...

We should have some principles that would help us define where the limits are needed and where they are not.

Additional context.

This was being raised/discussed during 2026-03-03 Specification SIG meeting.

Related issues:

• No limits for log record Body, SeverityText, and map/array count of AnyValue #4006

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[pellared]

@open-telemetry/technical-committee, I decided to just create the "parent issue" as I think we should first have some agreement/discussions on the principles before e.g. we decide to add the limits to instrumentation scope attributes.

[tigrannajaryan]

My opinion is that we should apply limits to all attributes.

Not having specified limits just means that the limits are unknown, not that they don't exist. It will result in those limits either being applied elsewhere (e.g. by a receiving backend that is well designed and will protect itself by truncating or rejecting the payload) or worse, will crash or OOM Otel SDK.

We can have higher limits for the Resource (and perhaps the Scope) since there is fewer of such attributes per payload compared to Span or Metric attributes, but nevertheless we need some limits.

At the same time, having the limits well defined in the spec is useful for designers of other participating systems (e.g. backends) to know what to expect instead of choosing arbitrary limits on their own, thus resulting in incompatibilities between vendors.

[jack-berg]

BTW, here's the spec that calls out that resource and metric attributes are exempt: https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/common#exempt-entities

Resources are also immutable by design and they are generally passed down to TracerProvider along with limits. This makes it awkward to implement attribute limits for Resources.

I disagree with this sentence. Resource is a config parameter of SDK TracerProvider, LoggerProvider, MeterProvider. So are attribute limits. Supposing the same attribute limits and resource is provided the providers, there's nothing awkward about those providers uniformly applying attribute limits to the resource before making it available for export.

We can have higher limits for the Resource (and perhaps the Scope) since there is fewer of such attributes per payload compared to Span or Metric attributes, but nevertheless we need some limits.

The default limits are:

• AttributeCountLimit: 128
• AttributeValueLengthLimit: Infinity

So we can't get any higher than the default length limit, and its hard to imagine that the count limit should be higher than 128.

But I was thinking about this more after the SIG and was realizing that there are two problems:

• When attribute count limits are exceeded, how do you avoid dropping the attributes that are critical to the identity (e.g. service.*)?
• Related but slightly different: for an edge case where a user sets an artificially low count limit such that there is no way to retain the identifying attributes, e.g. a count limit of 0 or 1, what should an SDK do?

Proposal for resource attributes: since resource attributes are known at initialization time, we have an additional option not available to scope or record attributes: fail fast. To side step the issues I mentioned above, if the resource attribute count limit is exceeded, fail fast. Apply attribute length limits normally. Since the default length limit is infinity, and since most identifying attributes are short, if a user does set a low enough limit to interfere with identifying resource attributes, that's their problem. Most users will set a reasonable length limit to avoid excessively long descriptive attributes.

[pellared]

My opinion is that we should apply limits to all attributes.

Not having specified limits just means that the limits are unknown, not that they don't exist. It will result in those limits either being applied elsewhere (e.g. by a receiving backend that is well designed and will protect itself by truncating or rejecting the payload) or worse, will crash or OOM Otel SDK.

What about other telemetry like Log Record Body, Span Name, Span Status Description etc?
Do we want to have all the data bounded?

[tigrannajaryan]

What about other telemetry like Log Record Body, Span Name, Span Status Description etc?
Do we want to have all the data bounded?

I think it should be bounded.

[tigrannajaryan]

BTW, a related approach is to impose limits on the entire payload byte size in serialized form. This is a much more crude way of expressing limits and it should be set at a high enough to allow legitimate messages and is usually entirely a system protection measure. However, it is difficult to enforce this type of limits such that localized truncation happens (it is hard to truncate just a single attribute while preserving the rest of the message intact).

I don't think this can be a replacement for attribute or field length limit, but wanted to have it here for completeness.

[pellared]

BTW, a related approach is to impose limits on the entire payload byte size in serialized form.

This is done in open-telemetry/opentelemetry-proto#782 for OTLP