Deployment-aware observability
Observe everything. Understand what changed.
Trace a regression back to the deployment, image, build or commit behind it.
ClueLake connects logs, metrics, traces, and Kubernetes deployments so you can monitor your systems, investigate performance changes, and trace regressions back to the deployment, image, build, or commit behind them.
- Kubernetes-native
- OpenTelemetry-native
- PromQL for supported queries
- eBPF visibility
What changed
deployment at 14:02The running image changed one minute before the regression. The previous digest is still available to roll back to.
Interactive demonstration — select a row
The problem
A graph tells you something changed. It doesn't always tell you what changed.
Production incidents often start with a spike in a chart and end with a long investigation across dashboards, logs, traces and deployment history.
Today
- Metric spike
- Search logs
- Open traces
- Check Kubernetes
- Inspect deployments
- Compare images
- Find commit
Seven tools, and the answer is held by whoever remembers what shipped.
With ClueLake
- Regression
- Deployment
- Image
- Build
- Commit
- Trace
One query. The change is already attached to the telemetry.
Deployment context
Your telemetry already knows what happened. ClueLake keeps the context.
ClueLake makes deployment context a first-class part of the observability model. These fields are stamped onto every event as it arrives, by the platform that performed the deployment — not read from the payload, which the workload controls.
- workspace_id
- environment_id
- application
- deployment_id
- image_digest
- build_id
- commit_sha
- replica
Because the fields are on the event rather than reconstructed afterwards, correlating a regression with the change that caused it is a query rather than an investigation.
What changed
See the regression and the change around it in one place.
ClueLake lines up the incident with the infrastructure events on either side of it, so the sequence is visible rather than reconstructed from memory.
Timeline
- 13:58Healthyp99 2.1s · errors 0.2%
- 14:02Deploymentcheckout-production · build #482
- 14:03p99 increased2.1s → 8.4s
- 14:04Error rate increased0.2% → 4.2%
- 14:05Rolled backto sha256:731f01
The change
- Previous image
- sha256:731f01
- Current image
- sha256:9ab3c2
- Build
- #482
- Commit
- a1b2c3d — cache: drop the per-request client
- Actor
- ada@example.com
Unified telemetry
Logs. Metrics. Traces. One investigation.
Bring the signals you already have together in a workflow designed for investigation. Keep the tooling that works — ClueLake is the backend the evidence lands in.
- ERRORupstream request failed: payments timeout after <n>ms1,829
- WARNconnection pool exhausted, waiting for a free connection640
- INFOhandling POST /api/checkout25,104
Every log line carrying a trace id links to its trace; every trace carries the deployment that produced it. The service map is built from trace relationships, and from eBPF flow data where it is available.
Cost control
Control observability cost before it becomes an invoice.
The usual complaint about observability billing is that the invoice is where you find out what you sent. ClueLake applies policy as telemetry arrives, and records every refusal with the series or attribute at fault.
- Raw telemetry
- Policy
- Accepted / sampled
- Stored
Cardinality
Keep runaway series under control. Budgets are enforced as data arrives, and an over-budget series is refused by name rather than dropped quietly.
Attributes
Define which dimensions belong in your telemetry. Allow lists, deny lists and redaction are applied at ingest, before anything is stored.
Tail sampling
Keep errors and slow traces while reducing routine volume. Control how telemetry is sampled rather than discovering it after the fact.
Query
Know what a query will read before you run it.
PromQL for the supported query set, log and trace search, and read-only SQL for everything else. Each query is costed first, so an expensive one is a decision rather than a surprise.
histogram_quantile(
0.99,
sum by (le, app) (
rate(http_request_duration_seconds_bucket{
app="checkout", env="production"
}[5m])
)
)Architecture
OpenTelemetry in. Your telemetry stays yours.
ClueLake is designed to fit the tooling you already use. Telemetry arrives over OTLP, and leaves through query APIs and exports — structured, and readable by things that are not ours.
- 01Kubernetes workloadsyour clusters
- 02OpenTelemetry · eBPF · Hubblecollection
- 03ClueLake ingestauth, tenancy
- 04Policy · sampling · enrichmentcardinality, redaction, deployment context
- 05ClickHousecolumnar storage
- 06Query · correlationPromQL, logs, traces, SQL
- 07ClueLake portalinvestigation
See the paths your application does not instrument.
Where a cluster runs Cilium and Hubble, ClueLake can use eBPF flow data to understand traffic and service relationships without application changes. It is used for service relationships and network telemetry — not as a substitute for application tracing.
Your telemetry should not become a hostage.
OpenTelemetry in, query APIs and exports out, and a documented storage model. Cold storage is designed around open columnar formats so the data stays readable outside ClueLake.
Security
Built for production telemetry.
Telemetry contains more about a business than most databases do. These are the architectural properties ClueLake is built on.
Tenant isolation
The workspace is the first key of every telemetry table, so tenancy is a property of the storage rather than a filter a query has to remember.
Scoped credentials
Ingest, query and automation keys are separate, bound to a workspace, and stored only as hashes. Tenancy is resolved from the credential, never from the payload.
Controlled query access
SQL is read-only and validated, with the tenant predicate injected by the server. Customers never receive database credentials.
Encrypted connections
TLS in transit throughout, with private networking between the control plane and its databases.
Role-based permissions
Owner, admin, member and viewer roles across organisations and workspaces.
Audit logging
Sign-in, credential and configuration changes are recorded append-only, enforced by the database rather than by application code.
Configurable retention
Retention is policy, set per environment, and applied by the storage engine.
Redaction policies
Deterministic attribute allow and deny lists, applied before storage. Sensitive headers are removed rather than the event being discarded.