Semantic Convention Attribute Level

Problem

Attributes that describe where telemetry comes from, like k8s.pod.name, container.id, or host.name, belong on the resource, stated once per batch. In your telemetry, some of them are attached to individual spans, metric datapoints, or log records instead, so the same value is repeated on every single record.

Insights checks over 150 semantic-convention resource attributes and flags ones appearing at the signal level.

Impact

• The same bytes are stored millions of times; depending on volume and which attribute leaks, the cost of storing that one attribute can multiply by 10-100x.
• High-cardinality identifiers like k8s.pod.uid multiply metric series counts on top of the duplication.
• Backends that group by resource stop recognizing records as coming from the same source.

Example

Repeated on every record:

# span attributes (every span carries these)
k8s.pod.name: checkout-7d9f4b-x2lqp
container.id: 8f2a41c7d8ab…
http.route: /checkout

Stated once:

# resource attributes (once per batch)
k8s.pod.name: checkout-7d9f4b-x2lqp
container.id: 8f2a41c7d8ab…

# span attributes
http.route: /checkout

How to fix

1. Find where the attribute is being set, usually a manual span.setAttribute call or a processor adding metadata at the wrong level.
2. Move it into the SDK’s resource configuration (or use the standard resource detectors, which place Kubernetes and host metadata correctly).
3. In a Collector pipeline, use the resource processor to set it, not an attributes processor that stamps every record.

Expected gains

Each resource value is stored once per batch instead of once per record: lower volume, smaller series counts, and backends that group your telemetry correctly again.

See the Insights catalog for everything Insights can detect.