feat(sdk-logs): add maxConcurrentExports to enable concurrent batch e…#8253
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #8253 +/- ##
============================================
- Coverage 90.32% 90.23% -0.10%
- Complexity 7651 7653 +2
============================================
Files 842 842
Lines 23075 23103 +28
Branches 2312 2316 +4
============================================
+ Hits 20842 20846 +4
- Misses 1514 1537 +23
- Partials 719 720 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I'm sympathetic to the issues you're discussing the PR description, but the behavior of BatchLogRecordProcessor is bound by the spec: https://github.com/open-telemetry/opentelemetry-specification The portion of the spec concerning BatchLogRecordProcessor contains normative language that explicitly prohibits calling export concurrently: https://github.com/open-telemetry/opentelemetry-specification/blame/083460ecc38dce5ed3b26ba142f2a2422c6f91e5/specification/logs/sdk.md#L537-L539 If you want to extend it with this type of capabilities, you'd have to work through the process to update the spec first. Alternatively, you can create your own copy of BatchLogRecordProcessor and customize to suit. |
Summary
This PR introduces a new configuration option
maxConcurrentExportsforBatchLogRecordProcessorto allow multiple export operations to run concurrently.By enabling controlled parallelism, this change improves log export throughput under high load while maintaining backpressure.
Motivation
Currently,
BatchLogRecordProcessorperforms exports sequentially, allowing only a single in-flight export at any given time. While this simplifies flow control, it can become a bottleneck in high-throughput scenarios, especially when:At the same time, switching to fully asynchronous export without limits can overwhelm downstream systems (e.g., OTLP receivers), leading to errors such as HTTP/2
REFUSED_STREAM.Changes
Add a new configuration parameter:
int maxConcurrentExports
Allow multiple export batches to be processed in parallel, bounded by
maxConcurrentExportsPreserve existing behavior by default:
maxConcurrentExports = 1(sequential export)Design Considerations
Controlled Concurrency
Instead of unbounded async exports, this approach ensures:
Backpressure
When the concurrency limit is reached:
Executor Utilization
This change allows better utilization of the underlying
LogRecordExporter, particularly when:ExecutorServiceBy enabling concurrent exports at the processor level, we avoid underutilizing available execution resources.
Compatibility
maxConcurrentExports = 1)