More tools emit OTLP every year, and more destinations accept it. If data is already flowing through Cribl and you need to push it to an OTel-compliant backend, the OpenTelemetry (OTel) Destination gets it there. That backend could be a commercial APM platform, a self-hosted Collector, Cribl Lake, or anything else on the growing list of vendors that support OTLP natively.
The destination is straightforward to configure. The real work is in what you do to the data before it goes out. Extract, process, rebatch. This page covers what that looks like and what to watch for.
HTTP or gRPC: pick one
HTTP (OTLP/HTTP) uses port 4318 by default and is the safer choice if your network path goes through load balancers, API gateways, or proxies. If you are on Cribl.Cloud managed worker groups, port 4318 is not available. Use a port in the 20000-20010 range instead.
gRPC (OTLP/gRPC) uses port 4317 and is faster and more efficient on the wire. Good fit if your stack is already gRPC/HTTP2-aware end to end.
Either works. HTTP is the lower-friction choice if you are not sure.
What you need before you start
- An OTel Source configured in Cribl with data flowing in: logs, metrics, spans, or some mix
- OTLP version set to 1.3.1 on your source if you are working with logs (the logs endpoint is not exposed on older versions)
- A destination that accepts OTLP, either a public HTTPS/gRPC endpoint or a Collector or agent setup that can receive it
- Auth credentials or bearer token if the destination requires them
Before you route anything to the destination, decide whether you need to extract signals at the source. If you are doing any pipeline work, masking, enrichment, filtering, or sampling, you need extraction on. If you are doing pure passthrough on a signal, you do not. This decision shapes everything downstream.
The pattern: extract, process, rebatch
OTLP arrives in batches. One export request can contain dozens or hundreds of individual log records, spans, or metric data points grouped under shared resource attributes. Without extraction, Cribl treats each resource grouping as a single event. That is fine for passthrough, but makes per-event processing impossible.
When you turn on Extract logs, Extract metrics, or Extract spans on your OTel Source, Cribl splits those batches into individual events, copies the resource and scope attributes down onto each one, and passes them through the pipeline one at a time. That is what makes it possible to mask a specific field, drop noisy spans, or enrich individual logs based on their content.
The tradeoff: those resource attributes are now duplicated across every event. If you had a batch of 100 logs, you now have 100 copies of the same resource context. Send them out as-is and your payload size jumps.
Rebatch before the data leaves Cribl. Use one of the OTLP pipeline functions to regroup individual events back into spec-compliant OTLP batches before they hit the destination:
- OTLP Logs Function -- rebatches log events by shared resource attributes, writes the shared context once at the top of the batch instead of repeating it N times
- OTLP Traces Function -- same pattern for spans
- OTLP Metrics Function -- handles metrics, including converting dimensional metrics like Prometheus into OTLP format. Also lets you control which fields become Resource attributes in the output batch
Debugging tip: run the OTLP functions without batching enabled first. The per-event view is much easier to inspect. Verify fields are landing where you expect and are not being dropped before you add the complexity of rebatching. Turn batching on once the per-event output looks right.
What to route to the OTel destination
Good candidates:
- Logs, spans, or metrics that need to land at an OTLP-compliant APM or observability backend (Dynatrace, Honeycomb, and 100+ others support native OTLP ingestion)
- Telemetry you have enriched or redacted in Cribl pipelines and need to forward in proper OTLP format
- Non-OTLP data you have converted into OTLP inside Cribl: syslog to OTLP logs, Prometheus metrics to OTLP metrics, and so on
- Spans you have tail-sampled, where you want to forward only the high-value subset to a downstream APM tool
If your destination is a row-based analytics store or a search platform that does not expect OTLP batch structures, skip rebatching. Keep the events flat and route them in extracted form. You can split the pipeline to do both. One branch rebatches for OTLP egress, another keeps events flat for storage or search.
One thing to sort out before you build your pipeline: for metrics, decide which fields should become Resource attributes in the rebatched output versus which stay as individual metric dimensions. That choice affects downstream labels, cardinality, and storage cost, and it is harder to fix after the fact.
Things that will trip you up
- Fields you add in pipelines that do not map to a known OTLP field will be silently dropped when the OTLP function serializes the output. If you are enriching events, keep the fields spec-compliant. Put them in
resource.attributesorattributeswhere OTLP expects them. - Payload size errors from the destination ("too many points per payload," "payload too large") usually mean you need to tune destination-level settings for max size or max events per transmission, not just the pipeline batch function.
- 401/403 auth errors: check bearer token format and confirm TLS is enabled on the source if the destination requires HTTPS.
- Events arriving at the destination missing resource context usually means rebatching is off, or the OTLP function is not seeing the internal fields it expects. Check that extraction was enabled at the source.
Check the destination status and Cribl internal logs first. The Live Data capture on the destination is pre-serialization, so it is human-readable but will not perfectly match the final binary protobuf payload. Use it to validate structure, then verify at the receiving end.
Resources
Knowledge Base
- Overview: Extract and Batch for OpenTelemetry in Cribl -- when to extract, when to rebatch, and when to skip it entirely
- Using Curl with OTLP over HTTP to test the Cribl OpenTelemetry Source -- useful checklist for validating your OTLP pipeline end to end
- How to Send Claude Cowork Monitoring Data to Cribl Stream -- real-world walkthrough of wiring an OTLP source to Stream and troubleshooting auth
Cribl Docs
- OpenTelemetry (OTel) Destination -- full reference for destination config, protocol settings, auth, and TLS
Cribl Blog
- OpenTelemetry Batches Like a Boss! -- how the OTLP Logs, Metrics, and Traces functions rebuild batches and why trimming Resource attributes before rebatching saves real money
- Simplify OpenTelemetry Metrics with Cribl Edge OTLP Conversion -- collecting system metrics, running them through the OTLP Metrics function, and sending them to an OTLP destination
- My 3 Lessons About OpenTelemetry for Observability -- good grounding on what OTLP actually is (and isn't) and how Cribl fits into the picture
- 7 Quick Tips for Working with Traces in OpenTelemetry -- span best practices including sampling, sensitive data, and resource attributes