The short answer
The Jaeger Collector drops spans when its in-memory queue between ingestion and storage fills faster than the storage backend can drain it. There is no single "drop threshold" flag: the drop metric increments whenever a span cannot be accepted into the internal queue (or, on the UDP path, when a datagram is lost or malformed before it ever reaches the queue). So the drop policy is effectively adaptive — it depends on heap pressure, queue size, and backend write latency at that moment, not on a fixed number.
What is confirmed vs. likely
Confirmed, well-established behavior:
- The collector exposes a dropped-spans counter (historically
jaeger_collector_spans_dropped_total; exact metric names vary by version) that increments when spans are rejected. - UDP and HTTP/gRPC ingestion behave differently: UDP loss can happen at the kernel socket buffer before Jaeger sees the packet, while HTTP drops happen inside the collector's queue.
- Sampling decisions reduce upstream volume and therefore indirectly change drop rates.
Likely, but you should verify on your deployment: that your drops correlate with backend latency (Elasticsearch bulk-index backpressure is a common culprit; Cassandra usually sustains higher write throughput but can still stall on compaction or node pressure).
Steps for this case
- Scrape the collector's metrics endpoint and correlate drops with queue and memory metrics:
curl -s localhost:14269/metrics | grep -E 'spans_dropped|queue_length|memory'
If drops rise while queue length sits near its maximum, the backend is the bottleneck. If the queue is low but drops still rise on UDP, suspect socket buffer loss instead.
- Check backend latency directly — Elasticsearch bulk request duration or Cassandra write latency — during the load window.
- If the queue is the limit, raise it and give the collector more heap, then re-test:
jaeger-collector \
--collector.queue-size=200000 \
--collector.num-workers=100
Flag names differ across Jaeger 1.x releases; run jaeger-collector --help on your version to confirm. Trade-off: a bigger queue delays drops but increases memory use and adds latency before spans reach storage — it absorbs bursts, it does not fix a chronically slow backend.
- If UDP is in play, check the OS receive buffer and packet size limits (
collector.udp-server.max-packet-size in some versions), and consider switching agents to HTTP/gRPC, which surfaces backpressure instead of silently losing datagrams.
Backend comparison under concurrency
Elasticsearch tends to show drops earlier because bulk indexing is sensitive to shard pressure, refresh intervals, and cluster state; the collector's ES writer applies backpressure that backs up the queue. Cassandra's write path is cheaper per span, so the same collector config usually sustains higher throughput — but hot partitions or compaction storms can produce the same symptom. The drop mechanism is identical; only the latency profile differs.
Caveats
Metric and flag names above reflect Jaeger 1.x behavior and should be verified against your version, since the project has been transitioning components to the OpenTelemetry Collector foundation in newer releases. Also note that spans filtered by sampling never reach the collector and do not appear in drop metrics — a high drop count plus a high sampling rate points to overload, not misconfiguration. If drops persist after the queue and backend checks, the one detail that would change this recommendation is whether drops occur on the UDP or HTTP path, since the fixes diverge there.
jaegertracing