Jaeger Collector ↔ Jaeger Query: How does sampling influence trace visibility?

In Jaeger, the Collector ingests spans via gRPC or Thrift and forwards them to a storage backend. The Query service then retrieves these spans and the UI renders a timeline view. A documented feature is the sampling mechanism, where the Collector drops a configurable percentage of traces to limit storage usage. This introduces a tension: higher sampling rates reduce storage load but can leave incomplete traces in the UI, while lower rates increase debugging fidelity but may degrade Query service performance when rendering large traces.

The goal is to understand the trade‑offs between sampling aggressiveness, trace completeness in the UI, and Query service load. Constraints include the need to support distributed tracing at scale and the fact that the UI cannot efficiently display traces with thousands of spans without performance degradation.

1. How does the sampling rate configured in the Collector affect which traces are stored and subsequently displayed in the Jaeger UI?
2. Does the Query service expose any parameters or endpoints that allow a client to request full, unsampled traces for debugging purposes?
3. What trace size thresholds (in terms of span count or latency) are recommended to avoid UI performance bottlenecks while still preserving sufficient detail for troubleshooting?