Add connection pooling support to OTLP exporter for high-throughput scenarios

[Arunodoy18]

Description

This PR adds connection pooling support to the OTLP exporter to resolve performance issues in high-throughput and high-latency environments.

Motivation

As reported in the issue, users experience unreliability in the OTLP exporter with:

• High throughput scenarios (10K+ spans/sec)
• High-latency network connections (e.g., cross-region deployments)
• AWS ALB limiting HTTP/2 streams to 128

The single gRPC connection becomes a bottleneck, causing queue overflow and dropped spans.

Changes:

##Core Implementation:

• *Added connection_pool_sizeconfiguration parameter** toConfig` struct

  • Default: 0 (uses 1 connection for backward compatibility)
  • Range: 0-256 connections
  • Validated in Config.Validate()

• Implemented connection pool in baseExporter

  • Maintains multiple gRPC connections in slices
  • Round-robin load balancing using atomic counter
  • All data types (traces, metrics, logs, profiles) use connection pool

• Thread-safe round-robin distribution*

  • getNextExporterIndex()method usesatomic.Uint32`
  • Optimized for single-connection case (no atomic ops)

Documentation

• Updated README.md with configuration details and examples
• Added changelog entry in .chloggen/
• Included high-throughput configuration example

Bug Fix

• Fixed unrelated service.go issue per contributor feedback on PR Update pdata comments #14342
  • Removed conditional process metrics registration

Testing

• ✅ All existing tests pass
• ✅ No compilation errors
• ✅ Configuration validation works correctly
• ✅ Backward compatible

Usage Example

``yaml
exporters:
otlp/high-throughput:
endpoint: otel-gateway:443
connection_pool_size: 5 # Creates 5 gRPC connections
compression: snappy
timeout: 20s
sending_queue:
num_consumers: 100
queue_size: 2000

[Arunodoy18]

I hope this works well, as was adressed through the issue .if any unrelated changes occur or anything which is wrong , please do tell after the review.
Thank you

[bogdandrutu]

Can you show me some data the demonstrate this is needed? gRPC says that you don't need to do this and it will automatically use multiple sockets, etc.

[tank-500m]

It doesn’t seem general enough to justify inclusion in the core component.
Also, there appear to be viable alternatives (e.g., the loadbalancing exporter in opentelemetry-collector-contrib).

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[github-actions]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[djluck]

@tank-500m I wanted to put across my perspective as a user that is running into this problem.

I wrote up #14249 that outlines the problem that this solution would solve.

To summarize why I think this would be a good change:

• GRPC uses a single connection but multiplexes over this connection, which brings a couple of disadvantages:
  • Connections are subject to HOL blocking at the TCP level
  • Some LBs (e.g. AWS ALB) put an upper limit on the number of concurrent streams a single connection can support
• Loadbalancing exporter is an option but requires maintaining duplicate DNS records and a chunk of repetitive configuration.

[Arunodoy18]

Thanks for pointing me back to this thread.

I understand now that I should have continued the discussion here instead of opening new PRs for similar approaches — apologies for the noise earlier.

For now, I’m not planning to push implementation changes. I’ll keep this thread in mind if there are future design discussions around OTLP exporter connection behavior or related performance topics.

In the meantime, I’ll focus on smaller, localized contributions while continuing to learn more about the Collector architecture and past design decisions in this area.

Thanks for the guidance.