Kubernetes generates the cardinality your metrics bill punishes.
Pods are born and die by the thousand, and every one is a new label value. Systems priced by unique series make Kubernetes the most expensive thing you run. CtrlB stores dimensions as columns, so churn costs bytes rather than multiples.
One deploy, two bills
Pod churn is free on bytes and brutal on series
A single rolling update replaces every replica, and every replacement mints a new label value. On per-series pricing that is a step change in your bill. On object storage it is a few hundred megabytes.
Every replacement pod mints a new value for pod.
namespace · prodcheckout-api6 replicasDashboards show the cluster.Investigations need the replica.
Pods churn by the thousand, and per-series pricing turns every rolling deploy into a budget event. The usual fix strips the one label you need when a single replica misbehaves.
Pod, node, namespace, and workload stay real dimensions — metric spike, OOM logs, and downstream trace correlate without switching tools.
Why Kubernetes breaks metrics pricing
What changes
Every pod restart mints new label values, so a rolling deploy can multiply your billable series overnight.
Keep pod, node, namespace, and workload as real dimensions, because a dimension costs storage rather than a series multiplier.
The mitigation is a relabel rule that strips pod identity — which removes exactly the dimension you need when one replica is misbehaving.
Repetitive container logs collapse into patterns automatically, so a noisy namespace becomes a short list instead of a wall.
Container logs are high-volume and mostly repetitive, so they get sampled just as an incident makes them interesting.
Logs, metrics, and traces from the cluster share one data layer, so a pod-level metric anomaly and its logs are one query apart.
Node, pod, and application telemetry land in three systems, and correlating them is manual.
Retention is a bucket lifecycle decision, so last month's incident is as searchable as this morning's.
Full-stack visibility, one data layer
Ship with the collector you already run. Keep every label. Investigate across logs, metrics, and traces without switching tools or reconciling three stores.
OTel Collector · DaemonSetno proprietary agent on every node
Ship with the collector you already run
Point your existing OpenTelemetry collector or Fluent Bit DaemonSet at CtrlB. No proprietary agent needs to go on every node.
| pod | namespace | p99 |
|---|---|---|
| checkout-api-7f9c-2xq4… | checkout | 104ms |
| checkout-api-7f9c-mk2d… | checkout | 812ms |
| checkout-api-7f9c-v4rn… | checkout | 111ms |
Keep every label
Pod, namespace, node, container, and workload all land as columns. There is no relabel rule to write and no cardinality budget to defend.
1.2 s span · same request id
Investigate across signals
Start from a spike in a per-pod metric, pivot to that pod's logs, then to the trace that produced them, without changing tools.
Cluster overview, built on the same lake
Events, counters, and utilisation are panels over the Parquet in your bucket — not a separate metrics store that has to agree with the logs.
Pod events
| Time | Pod | Reason |
|---|---|---|
| 08:41:43 | checkout-api-7f9c-mk2d | OOMKilled |
| 08:41:41 | checkout-api-7f9c-mk2d | BackOff |
| 08:41:38 | search-indexer-5d21-p8wq | Started |
| 08:41:22 | payments-worker-91af-tt3z | Scheduled |
| 08:40:57 | checkout-api-7f9c-mk2d | Unhealthy |
Running pods
across 3 clusters · 41 namespaces
Restarts by namespace
CPU requests vs limits
The replica that is actually broken
This is what the pod label is for. Aggregate it away to fit a cardinality budget and the middle row below stops existing — the workload just looks a bit slow.
| pod | p99 | restarts |
|---|---|---|
| checkout-api-7f9c-2xq4 | 104 ms | 0 |
| checkout-api-7f9c-hh8p | 98 ms | 0 |
| checkout-api-7f9c-mk2d | 812 ms | 3 |
| checkout-api-7f9c-v4rn | 111 ms | 0 |
Within SLO, no alert, nothing to page on — while a quarter of your checkout traffic takes eight times longer and the pod restarts every few minutes.
What you get
Per-pod granularity
Container log patterns
Multi-cluster
Collector fleet management
Ephemeral-friendly
OpenTelemetry native
“CtrlB gives us real-time visibility into our logistics systems — I can see critical events as they unfold.” — Ayush Lodhi, CTO & Co-Founder, GoComet. At OnBe, application, infrastructure, database, load balancer, and firewall logs share one data layer.
See what changed for these teamsQuestions
Only the OpenTelemetry collector, if you are not already running one. CtrlB does not require a proprietary node agent.
Yes. Metrics are stored as columns in Parquet rather than as series in a TSDB index, so adding a high-churn dimension adds bytes rather than multiplying a billable series count.
Yes. Cluster becomes a dimension like any other, so one query can span clusters, regions, and clouds.
PromQL is supported, so existing dashboards and recording rules carry over.
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.