# 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.

## Metadata

- **Canonical HTML**: https://ctrlb.ai/solutions/observability
- **Section**: Solutions — Observability

## At a glance

| Figure | What it refers to |
|--------|-------------------|
| 3 signals | One storage layer |
| OTel native | No proprietary agent required |
| #1 combined | On ClickBench, untuned |
| Scale to zero | Idle costs nothing to query |

## Why the stack fragments

- Logs 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.
- Correlating across them at 3 a.m. means three tabs and manual timestamp matching.
- Retention is set by whichever engine is most expensive per GB, so everything gets truncated to its limit.
- The 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

1. **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.
2. **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.
3. **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.

## Capabilities

- **Trace-to-log in one hop**: Traces and the logs they emitted share a data layer, so following a request across services does not mean switching tools.
- **Metrics without a TSDB**: Series live on object storage with no cardinality ceiling — see metrics at scale.
- **Schema-less logs**: New fields index as they appear. A deploy that adds a log field is not a pipeline change.
- **SQL you already know**: Aggregations, joins, and windows in standard SQL rather than a bespoke query DSL per signal.
- **Predictable cost**: Storage priced as storage, compute priced as compute, with no per-host or per-agent multiplier.
- **Portable by construction**: The lake is Parquet in your bucket. Any engine that reads Parquet can read your telemetry.

## FAQ

**Do we have to replace our collectors?**

No. CtrlB is OpenTelemetry-native, so existing OTel collectors and instrumentation point at it directly.

**Is this fast enough to replace a hot store?**

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.

**Can we run it alongside Datadog or Grafana?**

Yes — that is the usual starting point. See extending your existing stack.

**What about dashboards and alerting?**

CtrlB ships its own, and the streaming query engine evaluates alert rules continuously as data lands.

Markdown mirror: fetch `/solutions/observability.md` for this page as plain Markdown.