Exempt resources from attribute limits (#1892)
Resources are not susceptible to scenarios where excessive attributes can be recorded unlike Spans. Resources are also immutable and it can be hard for some SDKs to apply the limits at source at the time the attributes are added to a resource. Furthermore, limits and Resources both are generally defined and passed on to a TracerProvider which forces a TracerProvider to either mutate the resource or generate a new one with duplicate attributes in order to apply the limits to it. Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
This commit is contained in:
parent
8c6e0dd69c
commit
8d35d0c0fd
|
|
@ -90,6 +90,14 @@ followed by the global limit default value.
|
|||
|
||||
#### Exempt Entities
|
||||
|
||||
Resource attributes SHOULD be exempt from the limits described above as resources
|
||||
are not susceptible to the scenarios (auto-instrumentation) that result in
|
||||
excessive attributes count or size. Resources are also sent only once per batch
|
||||
instead of per span so it is relatively cheaper to have more/larger attributes
|
||||
on them. 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.
|
||||
|
||||
Attributes, which belong to Metrics, are exempt from the limits described above
|
||||
at this time, as discussed in
|
||||
[Metrics Attribute Limits](../metrics/sdk.md#attribute-limits).
|
||||
|
|
|
|||
Loading…
Reference in New Issue