Distributed Tracing Sampling Strategies Benchmark

Welcome to this survey on distributed tracing sampling strategies. Your participation is voluntary, and you may stop at any time. There are no right or wrong answers — we are interested in your actual practices and opinions. All responses are confidential and will be reported in aggregate only. This survey takes approximately 8–10 minutes to complete.

Which of the following tracing or observability tools have you used in the last 6 months? Select all that apply.

• OpenTelemetry
• Jaeger
• Zipkin
• Honeycomb
• Datadog
• New Relic
• AWS X-Ray
• Grafana Tempo
• Elastic APM
• Other
• None of the above

Which sampling approaches have you implemented or configured in the last 6 months? Select all that apply.

• Always on (head-based, 100%)
• Head-based probabilistic (trace-level rate)
• Rate-limited sampling
• Tail-based sampling
• Adaptive/dynamic sampling
• Per-endpoint or attribute-based rules
• I'm not sure
• None

At peak hours, approximately how many spans per minute does your system generate?

• Fewer than 1,000
• 1,000–10,000
• 10,001–100,000
• 100,001–1,000,000
• More than 1,000,000
• Unsure

To what extent do you agree: Our current sampling rate provides sufficient trace coverage for debugging production issues.

Scenario: A consumer-facing API averages 10,000 requests per second with periodic traffic spikes and a limited observability budget. Which baseline sampling strategy would you start with?

• Head-based probabilistic at a low fixed rate (e.g., 0.1–1%)
• Rate-limited head sampling with per-service quotas
• Tail-based triggers (errors/high latency) with a minimal baseline
• Always on (100%) to maximize coverage
• There isn't enough information to decide

Based on your responses in this survey, please share any additional thoughts or context about your tracing and sampling strategy.

What is your primary role?

• Backend/software engineer
• SRE/Operations
• Platform/Infrastructure
• DevOps
• Observability/Telemetry
• Data/Analytics
• Engineering manager
• Architect
• Other

Thank you for completing this survey — your responses will help improve tracing and sampling practices across the community. Your data will be reported in aggregate only.

How familiar are you with tracing sampling concepts (e.g., head-based, tail-based, rate-limited sampling)?

When using tail-based sampling, what most commonly triggers retaining a trace in your environment? Select the primary trigger.

• Error status codes
• High latency percentiles (e.g., p95/p99)
• Specific endpoints or attributes
• Adaptive scoring from backend
• Business events or SLO breaches
• Not applicable — I do not use tail-based sampling

Rank the following tracing objectives from most important (1) to least important in your environment.

1. Reducing observability costs
2. Faster debugging and root-cause analysis
3. Maintaining representative trace coverage
4. Meeting compliance or data-retention requirements
5. Supporting SLO monitoring and alerting

To what extent do you agree: The cost of storing and processing traces significantly influences our sampling decisions.

Briefly explain your reasoning for the sampling strategy you selected in the scenario above.

How many years have you worked with distributed systems?

• Less than 1
• 1–2
• 3–5
• 6–10
• 11+

What are the main reasons you have not adopted tail-based sampling? Select all that apply.

• Implementation complexity
• Infrastructure/resource constraints
• Cost concerns
• Data protection/compliance constraints
• Not needed for our use cases
• Lack of expertise or guidance
• Tooling/vendor limitations
• Not applicable — I already use tail-based sampling

To what extent do you agree: Configuring and maintaining sampling rules is straightforward in our current tooling.

We'd like to explore your sampling decisions in a bit more depth. An AI moderator will ask you a couple of follow-up questions based on your responses so far.

Approximately how many employees are in your organization?

• 1–49
• 50–249
• 250–999
• 1,000–4,999
• 5,000+

Where are sampling decisions primarily enforced in your current environment?

• SDK/agent level
• Collector/gateway level
• Backend/vendor-managed
• In-application custom logic
• Multiple layers
• Unsure

Rank the signals you most want your sampling strategy to capture reliably (1 = highest priority).

1. Rare high-latency outliers
2. Error spikes or regressions
3. Customer-critical endpoint issues
4. Incidents after new releases
5. Cross-service contention or bottlenecks

Which region do you primarily work in?

• North America
• Europe
• Asia-Pacific
• Latin America
• Middle East & Africa
• Other

How likely are you to adjust your sampling strategy in the next 3 months?