How It Works

One trace_id ties your whole system together

PeachTrace doesn't just store metrics, logs, and traces side by side — it keeps the OpenTelemetry context that lets you move between them.

A shared foundation

Every signal PeachTrace ingests — a metric point, a log record, a span — carries the same OpenTelemetry Resource and Scope model: the service name, environment, and instrumentation library that produced it. That shared context is what makes correlation possible in the first place, and it’s stored, not discarded, on every row.

shared resource & trace_id

Metrics

Time series scoped to the same service & resource attributes as your logs and traces.

Traces

Every span carries the trace_id and span_id that ties it back to its exact log lines.

Logs

Log records store trace_id/span_id directly, indexed for instant jump-to-trace.

Logs carry their trace context directly. Every log record has trace_id and span_id columns, populated automatically when your OpenTelemetry SDK emits a log inside an active span. Those columns are indexed, so jumping from a trace to every log line emitted during it — or from a single log line straight to its full trace waterfall — is a single lookup, not a time-range guess.

Open any span in the trace explorer and its correlated logs are one click away — no manual timestamp matching required.

Traces carry your database queries. Spans tagged with OpenTelemetry’s database semantic conventions (db.query.text, db.system, and friends) roll up automatically into Query Performance Insights — so a slow span isn’t a dead end, it’s a link to exactly which query ran, how often, and how it compares to every other execution of that query.

Metrics share the same service context. A metric series is scoped to the same resource attributes as your logs and traces, so when a metric spikes on checkout-api, you’re already looking at the right service to pivot into its traces and logs for that time window.

A walkthrough

  1. A latency metric spikes on checkout-api in the Metrics Explorer.
  2. You pivot to Traces, filtered to checkout-api for that window, and sort by duration.
  3. You open the slowest trace and follow the waterfall to the span that’s eating the time.
  4. That span has correlated logs attached — you see exactly what the service logged while it ran.
  5. If the span is a database call, its query shows up in Query Performance Insights, with a p95/p99 histogram showing whether this run was typical or an outlier.

No copy-pasting timestamps between three different tools. It’s one connected system because it’s one database.

Standard OTLP, nothing proprietary

PeachTrace speaks OTLP over gRPC (port 4317) and HTTP (port 4318) — the standard OpenTelemetry Collector protocol, using upstream OpenTelemetry proto definitions. Point any OpenTelemetry SDK at it the same way you’d point it at any other OTLP-compatible backend. There’s no proprietary agent to install and no vendor-specific instrumentation to adopt.