Default UDP reporter protocol limits Jaeger production trace delivery
0 reputation · 26 Aug 2021, 20:58 UTC
0 reputation · 26 Aug 2021, 20:58 UTC
Jaeger agents default to reporting spans to collectors over UDP on port 6832. While this default is convenient for local development and flat networks, production environments with firewall rules, TLS proxies, or container network policies may block or drop UDP traffic. When that happens, traces can disappear silently without triggering application errors, leaving operators unable to tell whether the loss stems from sampling, network segmentation, or reporter configuration.
The unresolved decision is whether production deployments should treat the default UDP reporter as an unsupported assumption or whether the agent provides a supported path to detect and adapt to network constraints. Without a clear boundary, teams may discover trace gaps only after incidents.
Does the default UDP reporter protocol have documented production limitations in segmented or zero-trust networks? Should the agent reporter protocol be explicitly overridden when network policies block UDP, and if so, what configuration boundary applies? How can operators confirm that the agent's reporter protocol aligns with the collector's expectations without relying solely on observed trace volume?
34775 reputation · 27 Aug 2021, 03:05 UTC
Yes. The default UDP reporter has real production limitations in segmented or zero-trust networks and should be treated as a development-only assumption. When network policies block UDP, explicitly override the agent reporter protocol to TCP or gRPC and align the collector listener to match. Confirm alignment through collector-side metrics and network-path checks, not by watching trace volume alone.
Established behavior: Jaeger agents report spans to collectors over UDP by default, commonly on ports 6831 and 6832. UDP is connectionless, so the agent receives no acknowledgment; a dropped packet is invisible to the application. Jaeger also supports TCP and gRPC reporter channels, and client SDKs can bypass the agent to report directly to a collector over HTTP or gRPC.
Likely failure mode: In production, missing traces usually stem from UDP being discarded by firewalls, Kubernetes NetworkPolicies, cloud security groups, or MTU fragmentation—not from sampling. Because the reporter is fire-and-forget, these losses are silent and appear only as gaps after an incident.
tcpdump on the agent host to confirm packets leave the interface and to look for ICMP unreachable messages. Run nc -u -z <collector-host> 6831 to test basic UDP reachability, but treat a passing result as insufficient proof.Version note: Default ports and flag names can vary across Jaeger releases and Helm charts. Confirm the exact reporter configuration keys for your deployed version before applying changes.
Is the collector reachable over TCP or gRPC from the application pod itself? If yes, overriding the agent reporter is the lower-risk change. If the application pod cannot reach the collector directly, keep the agent but switch its reporter protocol; direct-to-collector reporting would add resource overhead and may not be feasible under the current network policy.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.