Tail Sampling with Otel + Gigapipe

Search for a command to run...

Yes! Here's exactly how — and the one thing you should know before you do it.

How static thresholds create alert fatigue — and what actually fixes it.

You shipped the agent. It works. Users are happy. Somewhere in the background, tokens are flowing, latency is creeping, and your API bill is doing things you haven't looked at closely enough. We've se

As observability becomes a cornerstone of modern infrastructure, organizations are turning to platforms like Grafana Cloud and Datadog to monitor logs, metrics, and traces. However, these tools often come with hidden complexities, not just in their f...


In modern observability, capturing and storing every trace can quickly become impractical due to storage costs and noise from less relevant data. Tail sampling is a powerful technique that enables smarter trace retention by evaluating full traces before deciding whether to keep them. Let’s see how we can leverage this in combination the gigapipe polyglot stack.
Unlike head-based sampling, which makes decisions at the start of a trace, tail sampling occurs after a trace is completed. This approach provides richer context, ensuring important traces—such as slow requests, errors, or specific customer interactions—are retained for analysis. The OpenTelemetry Collector supports tail sampling through its tailsamplingprocessor, allowing for advanced filtering and retention policies.
qryn is a high-performance observability backend, acts as a native OpenTelemetry receiver, ingesting traces, logs, and metrics offering native LogQL, PromQL and Tempo compatibility.
By integrating the OpenTelemetry Collector with qryn, organizations can benefit from a seamless pipeline where tail sampling decisions are made before storing data in qryn. This setup optimizes both storage efficiency and query performance.
To enable tail sampling with qryn and OpenTelemetry, follow these key steps:
Deploy OpenTelemetry Collector – Ensure your collector is set up to receive traces from applications and forward them to qryn.
Enable the Tail Sampling Processor – Define sampling rules in your otel-collector-config.yaml, such as retaining traces based on status codes, duration, or custom attributes.
Export to qryn – Configure the collector to send selected traces to qryn’s OpenTelemetry-compatible API.
receivers:
otlp:
protocols:
grpc:
http:
processors:
tailsampling:
decision_wait: 10s
policies:
- name: error_traces
type: status_code
status_code:
status_codes: [ERROR]
- name: long_traces
type: latency
latency:
threshold_ms: 1000
exporters:
otlphttp:
endpoint: "http://qryn-gigapipe/api/v1/traces"
service:
pipelines:
traces:
receivers: [otlp]
processors: [tailsampling]
exporters: [otlphttp]
Reduced Storage Costs – By retaining only high-value traces, organizations can significantly cut down on observability storage expenses.
Improved Query Performance – Less noise in the dataset leads to faster and more meaningful trace analysis.
Enhanced Decision-Making – Tail sampling enables intelligent data retention, keeping critical issues and performance bottlenecks visible.
By combining OpenTelemetry’s tail sampling capabilities with qryn’s scalable and efficient backend, teams can fine-tune their observability pipelines for optimal performance and cost-effectiveness. Implementing tail sampling ensures that only the most relevant traces are retained, enabling deeper insights and better troubleshooting without unnecessary data overload.
Sign up for a free trial account at Gigapipe. Bring your own OTEL Logs, Metrics and Traces to enjoy our truly polyglot observability platform.