Unified data infrastructure
GitHub Let's talk

Observability

Metrics, logs and traces from one source of truth.

Observability is the workload that made separate systems normal: metrics, logs and traces have different shapes, and answering one question usually spans all three.

See Time-series Workloads All of Infrastructure & Technology

A latency question spanning the series, the trace and the deploy that caused it.

The story

A latency question spanning the series, the trace and the deploy that caused it.

Where it starts

Metrics

Counters, gauges, histograms and derived rates. It is the first of 4 workloads running in Observability.

The question it raises

One question across shapes

A latency question reads the series, the trace and the deploy record in one request instead of three tools.

Why one question is hard

From Instrument to Diagnose

Observability data moves through 4 stages — Instrument → Collect → Correlate → Diagnose. The shapes in play are Time series, JSON / documents, SQL, Events, and answering one question means reading across all of them.

What PLOMID contributes

Observability is the clearest case for one layer, because the question never respects tool boundaries.

  • Time-ordered storage Measurements and events are stored beside the records and documents they describe, so history and current state agree.
  • One data layer Rows, documents and time-ordered events live in one system, so a question is asked once instead of once per store.
  • Predicates narrow the work Indexes and access paths decide what a query touches before a page is read, so operational reads stay bounded.
The environment

Metrics, logs, traces and the service records they describe.

Metrics are dense time series, logs and trace events are high-volume records, and services and deploys are structured records. PLOMID holds them in one layer so a question can span the series, the event and the deploy that caused it, rather than ending at the boundary between three tools.

Workload architecture

The system reading itself.

Planning, execution and transactions first — then the workloads that use them and the shapes they name.

Observability · workload architecture
Workloads

What runs against this data.

  • Metrics
  • Logs
  • Traces and spans
  • Service and deploy records
Data models

The shapes those workloads read and write.

  • Time series
  • JSON / documents
  • SQL
  • Events
The layer

One path from a request to the data it names.

  • Planning Predicates narrow the work before it runs
  • Execution Records, fields and windows answered together
  • Transactions Readers and writers do not block each other
Surfaces

How the work reaches the layer.

  • SQL surface The query language the layer is documented in
  • Applications Services and jobs writing and reading as they run
  • Analytics & AI clients The same layer, the same access path
One environment · many workloads

What runs against observability data.

4 workload families over one set of shapes. Choose one to see what it moves and where it lands.

Counters, gauges, histograms and derived rates.

  • Planned once against the layer, not once per store
  • Read beside the records it shares a key with
  • Persisted under one storage contract
The data journey

How observability data reaches one layer.

Walk the path the data takes, from the environment that produces it to the questions it answers. Select a station, or a shape, to read each step.

A latency question spanning the series, the trace and the deploy that caused it.

Environment

The service

Services and infrastructure producing measurements about themselves.

Time series

Data models in play

The shapes, in one layer.

4 shapes carry this domain. Choose a stage to read the operation, or a shape to see every stage that handles it.

PLOMID · Observability instrument · collect · correlate · diagnose Select a stage
Stage

Instrument

Metrics from services and infrastructure

Time series

Workload map Observability workload map. Every shape on it is a surface of the layer, and each stage names the part of the operation it carries.
  • Time series Measurements and events in time order
  • JSON / documents Documents and nested objects
  • SQL Records, keys and joins
  • Events Operational events as they happen
Where the data goes to work

Questions a fleet asks about itself.

Each one reads telemetry with the records that explain it, from the same layer rather than a sidecar store.

One question across shapes

A latency question reads the series, the trace and the deploy record in one request instead of three tools.

  • Time series

Deploy attribution

Version and deploy records sit beside the measurements that changed after them.

  • JSON / documents
  • Events

Retention you control

Retention is a property of one layer rather than three vendor settings.

  • SQL

Structured logs stay queryable

Log fields are queried as data, not only scanned as text.

  • JSON / documents
  • SQL
Deployment & residency

Where this data is allowed to run.

Telemetry volume is highest close to production, so aggregation points and retention policy matter as much as the queries.

Deployment, residency and control
What you build next

Time-series Workloads

Measurements and events stored beside the records they describe.

If One question across shapes is your question, start here.

See Time-series Workloads Every solution
Next

Where to go next

Solutions The workload answers this industry leans on, with their models and status. Platform The data models in the product today, and the ones extending the layer. Architecture How a request is planned, executed and persisted once it reaches the layer.