OpenTelemetry in. Open Parquet out.
OTel solved vendor lock-in at the collection layer and stopped there — most backends still take open telemetry and put it into a proprietary index. CtrlB keeps the whole path open, from the collector to the files in your bucket.
Schema-less ingest
The attributes survive the trip
OpenTelemetry's value is in the attributes your services attach. A backend with a fixed schema keeps the ones it declared in advance and silently discards the rest — including the one the next incident turns on.
not in the schema, so not stored — and not recoverable later
schema-less ingest · every attribute queryable
The attribute you did not think to declare is the one the incident turns on. Here that is feature_flag.variant — the difference between “checkout is slow” and “checkout is slow on v3”.
Open on both endsInstrumentation stays portable. Storage should too.
OTel solved vendor lock-in at collection — most backends still take open telemetry and bury it in a proprietary index. The open path should run all the way to the files in your bucket.
OTel in → vendor schema → history you cannot export
logs + metrics + traces → s3://telemetry/lake/
Where the open path stops
- You instrumented with OTel to stay portable, then sent it to a backend whose storage format you cannot read.
- Switching backends means re-pointing collectors and abandoning the history the old one holds.
- Semantic conventions get flattened into whatever the vendor's schema expects, and the fidelity is not recoverable.
- Three signals arrive over one protocol and then land in three separate stores anyway.
What changes
- Collectors point at CtrlB with no vendor agent in the path and no instrumentation changes.
- All three signals land in one lake as open Parquet, in a bucket you own, readable by any Parquet engine.
- Schema-less ingestion preserves attributes as sent, including the ones your backend would have dropped.
- Because collectors fan out, you can run CtrlB beside your current backend for as long as the comparison is useful.
How it works
Add CtrlB as a second exporter, run in parallel with your current backend, and compare the same investigation against both — no cutover date required.
your config · your instrumentation
kept during evaluation
second exporter · fan-out
parallel run · no cutover date
Add an exporter
Add CtrlB as a destination in your existing collector config. Keep the current backend as a second exporter during evaluation.
Land all three signals
Logs, metrics, and traces write into one Parquet lake with their attributes intact, rather than into three stores with three schemas.
same files · no tool switch
Query one layer
Full-text search, SQL, and PromQL read the same files, so trace-to-log and metric-to-log are joins rather than tool switches.
One line in the pipeline you already run
Receivers and processors stay exactly as they are. CtrlB is an exporter, which is why adopting it is a config change rather than a project — and why nothing has to be switched off on day one.
The whole change, in six lines
Add the exporter, add it to the pipelines you want mirrored. Your existing exporter stays in the list, so both backends receive the same data and you can compare them on your own timeline.
exporters:
otlphttp/ctrlb:
endpoint: https://ingest.ctrlb.ai
service:
pipelines:
traces:
exporters: [existing, otlphttp/ctrlb]Whatever your services are written in
CtrlB takes OTLP, so the instrumentation story is OpenTelemetry’s, not ours. Anything that can export OTLP already works.
What you get
OTLP native
Semantic conventions kept
Collector fleet control
Parallel running
Vector and Fluent Bit
Portable history
“Tracing in CtrlB has completely changed how we debug issues at Blitz. We can follow requests across services in seconds instead of hours — it’s cut down our RCA time massively.” — Gaurav Piyush, CTO. GoComet runs the same OTel-native stack across its logistics systems.
See both OTel stacksQuestions
No. If you already emit OTLP, adding CtrlB is a collector configuration change.
Yes, and that is the recommended way to evaluate. Configure two exporters and compare the same investigation against both.
Yes. Ingestion is schema-less, so attributes land as sent and new ones index the moment they appear.
Vector, Fluent Bit, and direct HTTP ingestion are supported for sources that have not moved to OTel.
Put it on your own bucket and see.
Point a source at CtrlB, keep everything else where it is, and compare the same investigation side by side.