open-telemetry / open-telemetry/opentelemetry-java
Setting `round_robin` load balancing policy
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 2.5k
- Forks
- 1k
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 58
Description
In our k8s cluster, following gRPC best-practise our OTEL collector exposes its gRPC endpoint as a "headless service" (i.e. with multiple A record IP addresses).
The Go OTEL library allows us to specify the gRPC service config, and in it include the load balancing config, which I think is something like the below:
"loadBalancingConfig": {
"round_robin": {}
}
This works great with our Go-based services.
However, the Java OTEL library does not seem to offer this level of control, and you're forced to construct and manage your own gRPC channel.
It would be fantastic if there were some way to specify the load balancing policy, in the same way as the RetryPolicy.
Describe the solution you'd like
A new setter?
It also sounds like the Java gRPC ecosystem should respond well to a URL of dns:///my-endpoint.headless.service....:4167, but the OTEL library explicitly blocks this.
Additional context
Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how the Java OTEL library configures its gRPC channel and how RetryPolicy is exposed, then inspect the handling that blocks dns:/// endpoints. The work is done when callers can configure round_robin load balancing or use the documented headless-service endpoint without constructing their own channel.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- grpc, java
- Domain
- backend, networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100