sixty

DriftStore / investigation-first telemetry

Your telemetry should do more than sit there.

Store traces, metrics, and logs in one engine built to investigate anomalies—not just return rows. DriftStore follows a regression across signals, tests competing explanations, and shows exactly what the evidence can support.

  • OTLP nativemetrics · traces · logs
  • Tenant isolatedidentity from credentials
  • Replayablepinned evidence, not vibes
Investigation completecheckout-api / release 7f3a2c
ANOMALY 0142Checkout latency changed after deploy
STRONG
p95 latency+118%
baselinedeploy 7f3a2ccurrent
EXPLANATIONInventory calls moved onto the critical path

Present in 91% of affected traces and 8% of matched controls.

POST /checkoutdb.reserveinventory.check
3 signals joined2 contradictions tested14 witnesses

Most observability databases answer the query you already knew to ask.

DriftStore starts with the anomaly—and works backward to the evidence.

NATIVE LLM NARRATIVE / VERIFIED BY THE ENGINE

Let the model explain it. Never let it make the case.

DriftStore builds the facts, tests the hypotheses, and grades the evidence first. The model receives only that approved claim graph, then turns it into an incident narrative whose numbers and citations are checked before you see it.

Temporal topology12:38 → 12:46 UTC
EDGEapi-gateway
24ms
SERVICEcheckoutp95 +118%
+162ms
SERVICE · NEW EDGEinventory91% of affected
31ms
DATABASEpostgres
unchanged
SERVICEpaymentscontrol
observed edge changed edge appeared after deploy
Verified narrativemodel output · 6/6 atoms valid

Checkout p95 latency rose from 184ms to 401ms after release 7f3a2c. [M1]

The best-supported explanation is a new synchronous call from checkout to inventory. It appears in 91% of affected traces versus 8% of matched healthy controls and contributes a median 162ms to the critical path.[T4, C2]

Database time and payment latency did not materially change, weakening the two competing explanations. [N1, N2]

CLAIM LEVELExplanatory
CONTRADICTIONS2 tested · 0 disqualifying
COVERAGE86% eligible traces
What the model cannot do
  • Invent a fact
  • Change a number
  • Upgrade a claim
  • Hide missing coverage
  • Recommend without a basis

ONE TIMELINE. THREE SIGNALS.

Correlation without the tab switching.

Metrics locate the change. Traces expose the changed request shape. Logs provide the exact witness. Every step keeps its provenance.

01 / METRICS

Find where behavior drifted.

PromQL-compatible queries, exemplars, adaptive rollups, and change-point detection over the same retained history.

02 / TRACES

See what the request started doing.

Move from a metric regression into exact trace shapes, critical-path contributors, and representative witnesses.

03 / LOGS
12:41:08stock lookup timed outtrace=8f21…

Read the line that proves it.

Query logs in context, joined by trace, service, release, environment, and the investigation window.

MEASURED, NOT PROJECTED

Fast at the receiver. Complete after it.

Three-trial, open-loop OTLP studies on an isolated host. Every displayed run had zero client drops and zero HTTP errors; the workload, ACK boundary, and downstream gate are stated so a latency number cannot quietly become a durability claim.

METRICS · 300,007 POINTS/S0.836 msDriftStore receiver p99
VICTORIAMETRICS0.901 ms7.3% higher p99

Both engines accepted and exposed exactly 18,000,400/18,000,400 points in every trial. DriftStore used more resources at this operating point: 153.3% median CPU and 250.7 MiB median RSS versus 44.7% and 162.8 MiB.

Signal / comparatorOffered loadDriftStore p99Comparator p99Result
MetricsClickStack400k points/s0.935 ms3.892 ms76.0% lower
TracesClickStack32k spans/s0.383 ms2.033 ms81.1% lower
LogsClickStack16k records/s0.309 ms2.198 ms86.0% lower
MetricsVictoriaMetrics300,007 points/s0.836 ms0.901 ms7.3% lower
WHAT THE ACK MEANS

DriftStore reports bounded, memory-buffered admission before gzip inflation and protobuf decode. ClickStack decodes before its collector response. Neither response is a durable-storage ACK; moving decode off the response path is a deliberate DriftStore architectural advantage.

WHAT IS FULLY GATED

The VictoriaMetrics row has point-level completeness on both engines. The ClickStack runs gated exact ClickHouse rows and exact DriftStore compacted frames; point/span/log enumeration on DriftStore remains a stricter follow-up gate.

WHAT WE DO NOT CLAIM

These operating points do not prove maximum capacity, equal durability, query latency, long-retention storage efficiency, or lower resource use. VictoriaMetrics remains substantially more CPU- and memory-efficient in the measured metrics run.

Candidate results, recorded August–September 2026. The source, runners, raw trials, image digests, and limitations are public: ClickStack signal study ↗ · ClickStack metrics study ↗ · VictoriaMetrics study ↗

THE DIFFERENCE

An answer you can inspect. Including “not enough evidence.”

  1. 01
    Measure the change

    Baseline and current windows use the same typed measure, with coverage and sampling made explicit.

  2. 02
    Generate competing explanations

    Cross-signal candidates are ranked from storage-native facts—not invented by a language model.

  3. 03
    Try to disprove them

    Matched controls, unaffected cohorts, contradictions, and negative controls challenge every claim.

  4. 04
    Grade—or abstain

    The result is observed, corroborated, explanatory, or insufficient. Missing data never becomes certainty.

NOT JUST FEWER BOXES

The investigation is the data model—not a workflow assembled afterward.

Loki, Mimir, and ClickHouse are powerful systems. DriftStore is better when the job is explaining an anomaly across signals with a result you can replay and audit.

ASSEMBLED OBSERVABILITY STACK
Mimirmetrics+Lokilogs+trace storetraces+ClickHousecustom joins
  • You define the joins.Trace IDs, release identity, topology, and windows have to line up across systems.
  • You author the investigation.Dashboards and queries expose signals; people or custom agents decide what to test next.
  • The answer is ephemeral.Query results can come from different retention states and storage generations.
  • An LLM sees query output.Guardrails, citations, contradiction tests, and claim limits become application code you own.
DRIFTSTORE
metricstraceslogsone evidence graph
  • Joins are native.Exemplars, trace shape, logs, temporal topology, release, and code change share one investigation vocabulary.
  • Falsification is automatic.Matched cohorts, negative controls, competing contributors, and coverage gates run as bounded storage operations.
  • Every answer is replayable.The artifact records exact windows, checkpoints, algorithms, limits, evidence, and contradictions.
  • The LLM is the narrator.It verbalizes approved claims. The engine remains the authority—even when inference is unavailable.

Choose the stack when: you need general-purpose, independently operated signal stores and want to build your own investigation layer. Choose DriftStore when: the product you want is the investigation.

BUILT FOR THE HOT PATH

A storage engine, not a dashboard glued to someone else’s database.

Rust on the write path. Checksummed WAL frames. Immutable zstd segments. Tenant-safe pruning. Hot, compacted, and archived data read through one checkpoint-pinned view.

Explore the architecture →
Live data pathcheckpoint 8,412 · healthy
OTLP / HTTPgRPC streamPrometheus
01 · DURABLE INGESTChecksummed WAL
bounded async ACK
02 · QUERY STORAGEImmutable segments
  • zstd
  • adaptive indexes
  • tenant-pruned
QUERYPromQL + DriftQLcheckpoint-pinned reads
INVESTIGATEEvidence artifactfacts · claims · contradictions

YOUR DATA ALREADY KNOWS WHAT HAPPENED.

Make it explain itself.

Send standard OpenTelemetry. Keep the evidence. Investigate the next anomaly from one place.

DriftStore — telemetry that investigates itself