Jaeger Agent UDP Port Binding for Repeatable Development Environments

Question

Goal: configure the Jaeger Agent so that its UDP listeners (6831 for Thrift compact, 6832 for Thrift binary) are bound to predictable host ports in a repeatable development environment, ensuring that instrumented applications always send traces to the same address.
Uncertainty: the Jaeger Agent does not enforce a fixed binding address unless explicitly supplied; when the host port mapping is omitted (e.g., docker run jaegertracing/all-in-one), Docker may allocate random high ports, causing non‑deterministic trace collection and potential collisions when multiple agents run concurrently in CI pipelines.
Specific questions:

Should development manifests require an explicit static host‑port mapping (e.g., -p 6831:6831 -p 6832:6832) to guarantee repeatable trace collection?
Is it acceptable to rely on Docker’s dynamic port assignment and use service discovery or environment variables to propagate the actual host ports to tracing clients?
What are the operational trade‑offs between enforcing static bindings (risk of port‑already‑in‑use failures) and allowing dynamic allocation (risk of trace loss or misrouting) in a repeatable dev setup?

Tasadduq Burney · Answer

Answer
Yes – for a repeatable development environment you should map the Jaeger Agent’s UDP listeners to fixed host ports (e.g., -p 6831:6831/udp -p 6832:6832/udp). This guarantees that instrumented applications always send traces to the same address.
Explanation vs. Confirmed Facts
Likely explanation: When the host‑port mapping is omitted, Docker may allocate random high ports for the container’s UDP sockets, making the agent’s listening address non‑deterministic and prone to collisions in CI pipelines.
Confirmed facts: The Jaeger Agent listens on UDP 6831 (Thrift compact) and UDP 6832 (Thrift binary) by default, unless overridden via --udp-port or the JAEGER_AGENT_UDP_PORT environment variable. Binding to a fixed UDP port ensures clients can be configured with a deterministic endpoint.
Steps Needed for This Case

Choose the UDP ports you want to expose (the defaults 6831 and 6832 work fine).
Start the Jaeger Agent with explicit host‑port mapping:
docker run -d \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  jaegertracing/jaeger-agent:latest

If you prefer to override the ports, pass the flag or env var, e.g., --udp-port=6831 or -e JAEGER_AGENT_UDP_PORT=6831.
Configure your application’s tracer to point to localhost:6831 (or the host you chose) for UDP span submission.
Verify: check the agent’s startup log for a line like UDP listener started on 0.0.0.0:6831 and send a test span; confirm it appears in the Jaeger UI.

Operational Trade‑offs

Static binding: guarantees repeatability and eliminates port‑collision guesswork; the downside is a failure to start if the chosen port is already in use on the host.
Dynamic allocation: avoids port‑conflict errors but requires service‑discovery or environment‑variable propagation to tell clients the actual host ports, adding complexity and risk of misconfiguration or trace loss.

For most local‑dev and CI scenarios, the simplicity and reliability of static host‑port mapping outweigh the occasional port‑in‑use error, which can be resolved by choosing an alternative free port or stopping the conflicting process.

Jaeger Agent UDP Port Binding for Repeatable Development Environments

1 answer

Answer

Explanation vs. Confirmed Facts

Steps Needed for This Case

Operational Trade‑offs

Your perspective belongs here.

1 question comment