Which Prometheus metrics best support SLO alerting for Jaeger Adaptive Sampling?

Recommended Metrics for SLO Normalization

To prevent false positives during adaptive sampling shifts, you must avoid using raw span counts as a proxy for request volume. The recommended approach is to use extrapolated request counts by weighting sampled spans against the current sampling probability provided by the Jaeger collector.

Core Metrics for Alerting

While jaeger-query is useful for visualization, real-time SLO alerting should rely on jaeger-collector metrics to minimize latency and avoid query-side overhead. Focus on these signals:

• Sampling Probability: The current rate at which the adaptive sampler is accepting traces. This is the divisor used to normalize your counts.
• Spans Received/Accepted: The raw count of spans that passed the sampling filter.
• Dropped Spans: Metrics indicating spans rejected due to collector saturation (distinct from adaptive sampling), which signals a need for infrastructure scaling rather than sampling adjustment.

Implementation Logic

To calculate a reliable SLO (e.g., % of requests under 500ms), use a PromQL pattern that divides the sampled count by the sampling rate to estimate the actual traffic volume.

Normalization Formula:
Estimated Total = (Sampled Spans) / (Sampling Probability)

1. Calculate Estimated Total: Sum the spans received over the window and divide by the average sampling probability for that period.
2. Calculate Estimated Compliant: Sum the spans meeting your latency threshold and divide by the same sampling probability.
3. Compute SLO Ratio: Divide the Estimated Compliant count by the Estimated Total.

Assumptions and Limitations

This approach assumes that the adaptive sampler is unbiased—meaning it drops spans randomly across the latency distribution. If the sampler preferentially drops specific types of traces (e.g., only very short or very long traces), the extrapolated p99 will be skewed.

Uncertainty Note: Extrapolated metrics are statistical estimates. During rapid traffic spikes where the sampling rate changes aggressively within a single Prometheus scrape interval, you may see temporary "jitter" in the SLO ratio.

Verification Step

To verify your normalization logic, run a controlled load test and compare the jaeger-collector extrapolated total against your application's internal request counters (e.g., from an Envoy or Nginx sidecar). They should converge within a small margin of error.

Diagnostic Detail Needed: Are you using the Jaeger native adaptive sampling (via the adaptive-sampling component) or a custom sampling strategy implemented in a service mesh? The available Prometheus metric names differ between these two implementations.