OTLP Exporter Resource Attribute Persistence During Batch Processing
0 reputation · 19 Oct 2023, 11:40 UTC
0 reputation · 19 Oct 2023, 11:40 UTC
The OpenTelemetry Collector utilizes a pipeline architecture where telemetry signals are passed from receivers through processors to exporters. When employing the batch processor to optimize outgoing request volume, signals are grouped before being transmitted via the OTLP exporter using gRPC or HTTP/protobuf.
A design concern arises regarding the consistency of resource attributes when multiple signals with differing resource metadata are aggregated into a single batch. Since the OTLP protocol defines standard resource attributes for interoperability, it is necessary to understand how the collector maintains these attributes during the batching phase to prevent metadata loss or incorrect attribution at the backend.
34775 reputation · 19 Oct 2023, 12:42 UTC
Yes, the batch processor preserves unique resource attributes for each signal. In the OpenTelemetry (OTel) data model, telemetry is not sent as a flat list of signals; instead, it is structured as a collection of Resource Spans (or Resource Metrics/Logs). Each group of signals sharing the same resource metadata is encapsulated within a ResourceSpans object.
When the batch processor aggregates data, it does not strip the resource context. The OTLP exporter transmits a ExportTraceServiceRequest, which contains a repeated field of ResourceSpans. Each ResourceSpans message contains:
service.name, host.id).Because the resource attributes are tied to the ResourceSpans wrapper rather than the individual span, the OTLP exporter maintains a 1:N relationship between a resource and its associated signals within a single request. This prevents metadata loss and ensures correct attribution at the backend.
The OTLP exporter itself does not merge or drop attributes during transmission. However, attribute loss typically occurs due to the following pipeline configurations:
resourcedetection or transform processor is configured after the batch processor, it may overwrite or delete specific attributes across all signals in the batch.To verify that resource attributes are persisting correctly through your batching pipeline, you can use the debug exporter (formerly logging exporter) in your collector configuration:
exporters:
debug:
verbosity: detailed
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [debug]
Inspect the output logs for the Resource block. You should see distinct ResourceSpans entries if the batch contains signals from different resources.
Diagnostic Detail Needed: Are you using a custom transform processor between the batch processor and the exporter? This is the most common point where attributes are inadvertently dropped.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 19 Oct 2023, 23:15 UTC
When the BatchSpanProcessor hands a batch of spans to the OTLP exporter, the SDK does not merge spans with different resources. Instead, it builds one ResourceSpans message for each distinct resource present in the batch. Each ResourceSpans contains the resource attributes and a list of ScopeSpans (one per instrumentation library) that in turn hold the individual spans. Consequently, a single ExportTraceServiceRequest may contain multiple ResourceSpans blocks, preserving the original resource‑to‑span mapping.
This means that even if the batch size limit is reached, the exporter still sends a separate ResourceSpans section for each resource, ensuring that no resource attributes are lost or conflated during transmission.