OTEL-039: Position of Batching

[rafaelrodrigues3092]

First of all - thank you for this. I think this is a great initiative.
I was testing your tool this morning, and while I am still going through the output, one item quickly caught my attention.

The rule OTEL-039.
I had an output such WARN OTEL-039: pipeline 'metrics' has transform/attributes processor after batch.

The correct position of the batch processor is something that I have always gone back and forth on how to best implement it.
I landed on this:

• OTel Recommended Processors

I am opening this issue not necessarily as a bug, but to open a discussion on this particularly rule.
I'd like to hear your thoughts!

[starkross]

Thank you for engaging with this and helping improve the tool!

You raise a fair point. The official documentation does suggest that batch should come before processors like transform/attributes, since the latter would fall under "any other processors" in the recommended order. However, that guidance originates from a PR merged in February 2020 (open-telemetry/opentelemetry-collector#573), which is over 6 years ago – and I'm not confident that recommendation still reflects current best practice.

Looking at more recent real-world guidance, observability vendors are recommending placing batch closer to the end of the pipeline – after transformation processors. For example, a January 2026 post from OneUptime explicitly shows the recommended order as:

memory_limiter → resource → filter → attributes → transform → sampler → batch

The rationale makes sense: filter early to reduce load, transform only what you keep, and batch last to collect fully-processed data into efficient export payloads.

To be safe, I've also opened a question directly with the OTel Collector maintainers to clarify whether the documentation still reflects current best practice open-telemetry/opentelemetry-collector#15075

[rafaelrodrigues3092]

Thank you for engaging with this and helping improve the tool!

You raise a fair point. The official documentation does suggest that batch should come before processors like transform/attributes, since the latter would fall under "any other processors" in the recommended order. However, that guidance originates from a PR merged in February 2020 (open-telemetry/opentelemetry-collector#573), which is over 6 years ago – and I'm not confident that recommendation still reflects current best practice.

Looking at more recent real-world guidance, observability vendors are recommending placing batch closer to the end of the pipeline – after transformation processors. For example, a January 2026 post from OneUptime explicitly shows the recommended order as:

memory_limiter → resource → filter → attributes → transform → sampler → batch

The rationale makes sense: filter early to reduce load, transform only what you keep, and batch last to collect fully-processed data into efficient export payloads.

To be safe, I've also opened a question directly with the OTel Collector maintainers to clarify whether the documentation still reflects current best practice open-telemetry/opentelemetry-collector#15075

Thank you for this. This is exactly the type of insight I was going after.
In my use cases I used to have batch at the end of the pipelines, and based on official documentation I decided to move it earlier.
I appreciate you opening the ticket as well for clarification.

Looking forward to using your tool further, and even integrate it in my validation workflows.