One data layer for logs, metrics, and traces
Three telemetry types usually mean three storage engines, three retention policies, and three bills. CtrlB puts all of it in open Parquet on your object storage and answers every question from the same place.
One data layer
Three signals stop being three tools
Logs, metrics, and traces land in the same open Parquet, so a trace id, the log line it emitted, and the series it moved are one join apart instead of one tool apart — under one retention policy and one bill.
Why the stack fragments
01Logs go to one engine, metrics to a TSDB, traces to a third store — each with its own retention, its own query language, and its own copy of the truth.
02Correlating across them at 3 a.m. means three tabs and manual timestamp matching.
03Retention is set by whichever engine is most expensive per GB, so everything gets truncated to its limit.
04The always-on cluster runs at peak size all night so that the occasional query is fast.
What one layer buys you
One query surface across all three signals, so a trace id, a log line, and a series live one join apart rather than one tool apart.
One retention policy, set by what object storage costs rather than by the most expensive engine in the stack.
Stateless query nodes that spin up for the question and scale back to zero, so idle hours are not billed as compute.
OpenTelemetry in, open Parquet out. Nothing about the storage layer is proprietary.
How it works
Ship OTel
Point your existing collectors at CtrlB. Logs, metrics, and traces land schema-less in your bucket without a proprietary agent in the path.
Query one layer
Full-text search, SQL aggregation, and trace lookup all read the same Parquet. There is no sync step and no second copy to keep consistent.
Keep what you need
Retention is an object lifecycle policy. Old data stays queryable at the same speed rather than moving to an archive you have to restore from.
What you get
Trace-to-log in one hop
Metrics without a TSDB
Schema-less logs
SQL you already know
Predictable cost
Portable by construction
Same security agent. Same S3 data. Only the query layer changed.
View customer storyQuestions
No. CtrlB is OpenTelemetry-native, so existing OTel collectors and instrumentation point at it directly.
CtrlB places first on the combined ClickBench result, untuned, and does point search on petabyte log tables in under a second. The design goal is that there is no hot store to replace.
Yes — that is the usual starting point. See extending your existing stack.
CtrlB ships its own, and the streaming query engine evaluates alert rules continuously as data lands.
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.