One database, one engine​

Everything lands in a single ClickHouse database, otel, and almost every table is a plain MergeTree. There is no per-signal store to size, scale and back up separately — traces, logs, metrics and profiles are tables next to each other, on the same disks, in the same query engine.

The trace and log tables aren't hand-rolled. Their column contract is frozen verbatim from the OpenTelemetry Collector's ClickHouse exporter (pinned at 0.154.0), so the exporter can INSERT with an explicit column list and avuru's hub can read the exact same shape. That's the quiet superpower of building on OTLP: the storage schema is the OpenTelemetry data model, not a proprietary re-encoding of it.

The four signals, table by table​

Traces live in otel.otel_traces:

CREATE TABLE otel.otel_traces
(
    Timestamp          DateTime64(9),
    TraceId            String,
    SpanId             String,
    ParentSpanId       String,
    SpanName           LowCardinality(String),
    ServiceName        LowCardinality(String),
    ResourceAttributes Map(LowCardinality(String), String),
    SpanAttributes     Map(LowCardinality(String), String),
    Duration           UInt64,
    StatusCode         LowCardinality(String),
    -- Events.*, Links.*, skip indexes on TraceId / attrs / Duration …
)
ENGINE = MergeTree
PARTITION BY toDate(Timestamp)
ORDER BY (Tenant, ServiceName, SpanName, toDateTime(Timestamp));

A companion table plus a materialized view keep a TraceId → [start, end] index so "open this trace" is a narrow time-bounded read instead of a scan. TraceId and SpanId carry bloom_filter skip indexes; Duration gets a minmax index so "spans slower than X" prunes granules early.

Logs live in otel.otel_logs, and they carry the same TraceId, SpanId and ServiceName columns as spans do. On ClickHouse 26.x the log body and attribute maps get full-text text indexes, and the common Kubernetes resource attributes (k8s.namespace.name, k8s.pod.name, …) are materialized into their own columns so filtering by pod or namespace stays cheap.

Metrics are five tables — otel_metrics_gauge, _sum, _histogram, _exponential_histogram, _summary — one per OTLP metric type. All five are created even when only some are in use, because with a fixed schema a missing table means silently dropped inserts the day a new app starts emitting histograms. Each row keeps an Exemplars.TraceId / Exemplars.SpanId array — the thread that sews a metric data point back to the exact trace that produced it.

Profiling — the newest, opt-in signal — is the one schema avuru fully owns, because OTLP Profiles is still alpha and the exporter has no profiles support yet. It uses a two-table split so repeated stacks cost almost nothing:

-- Unique stacks stored once, keyed by a 64-bit hash.
CREATE TABLE otel.profiling_stacks
(
    Tenant    LowCardinality(String),
    StackHash UInt64,
    Frames    Array(String),
    LastSeen  DateTime DEFAULT now()
)
ENGINE = ReplacingMergeTree(LastSeen)
ORDER BY (Tenant, StackHash);

-- Samples reference a stack by hash instead of repeating frames.
CREATE TABLE otel.profiling_samples
(
    Timestamp   DateTime64(9),
    Tenant      LowCardinality(String),
    ServiceName LowCardinality(String),
    SampleType  LowCardinality(String),
    StackHash   UInt64,
    Value       UInt64,
    NodeName    LowCardinality(String),
    PodName     String,
    ContainerName LowCardinality(String)
)
ENGINE = MergeTree
ORDER BY (Tenant, ServiceName, Timestamp);

Errors: a fifth signal derived, not ingested​

Error tracking isn't a separate pipeline — it's a materialized view on top of the logs table. Any ERROR/FATAL record (OTLP SeverityNumber >= 17) is projected into an error_events table at insert time, with a stack-trace fingerprint computed in SQL: normalize hex addresses and line numbers, hash the top frames, and group identical crashes into one issue. Exceptions ingested from a Sentry-compatible SDK land in the same logs table (tagged at the gateway) and flow through the very same view — so browser errors and backend panics dedupe together, for free, with no extra store.

What makes them one store​

Look at the sort keys and you'll notice the same columns over and over: ServiceName, Timestamp, and above all TraceId. Because every signal is keyed on the OpenTelemetry resource and trace identity, correlation is a query, not an integration:

-- From a slow span straight to the logs that explain it.
SELECT l.Timestamp, l.SeverityText, l.Body
FROM otel.otel_logs AS l
WHERE l.TraceId = {trace_id:String}
ORDER BY l.Timestamp;

-- p99 latency per endpoint for one service, in the last hour.
SELECT SpanName, quantile(0.99)(Duration) / 1e6 AS p99_ms
FROM otel.otel_traces
WHERE ServiceName = 'checkout'
  AND Timestamp > now() - INTERVAL 1 HOUR
GROUP BY SpanName
ORDER BY p99_ms DESC;

A latency histogram's exemplar carries the TraceId of a representative request, so a spike on a dashboard links directly to the trace behind it — same store, one join. No trace_id-to-trace_id bridge to configure between separate systems.

And it's all one query language. There's no PromQL for metrics, a log query language for logs, and a third dialect for traces — it's SQL for all four, over tables you can inspect with SHOW CREATE TABLE.

A few deliberate choices​

• Partition by day, drop by part. Every table is PARTITION BY toDate(...) with ttl_only_drop_parts = 1, so retention is applied by dropping whole daily parts (fast) rather than row-level TTL mutations (slow). Retention windows are set at migrate time from the environment, not frozen into the DDL.
• The right index for the shape. Bloom filters for high-cardinality id/attribute lookups on traces and metrics; ClickHouse text indexes for full-text log search.
• A multi-tenancy seam that's free in single-tenant mode. Every table leads its sort key with a Tenant column that defaults to 'default'. With one tenant it's a single constant value — zero storage and sort cost — but the column that a hosted, multi-tenant deployment needs is already there.

Read the tables yourself​

None of this is hidden: the migrations that create these tables ship in the engine repo, and a running instance is one SHOW CREATE TABLE away. If you want to see the whole thing light up over OTLP, install in 30 seconds, skim the architecture, or read how avuru obs compares to the tools you already run.

Two ways to capture errors, no rewrite​

Derived from telemetry you already send​

avuru obs reads the exceptions already flowing in over eBPF and OTLP — span exception events, error spans and ERROR/FATAL logs — and groups them into deduplicated issues at insert time in ClickHouse. For a backend service that already exports to avuru obs, error tracking needs zero instrumentation: no SDK, no code change, no extra agent.

Sentry-SDK-compatible ingest​

For the errors eBPF can't see — browser exceptions above all — the gateway runs a Sentry-protocol receiver. Point an existing Sentry SDK's DSN at the avuru obs gateway and its events flow into the same store. You keep the SDKs you already run and change a single config value.

One store, correlated by default​

Because every error shares a trace_id with the rest of your telemetry, an issue links straight back to the trace that produced it, the logs around it, and the metrics and profiles for that service — no jump to a separate tool. It's one ClickHouse to size, back up and query, instead of a separate error database bolted on beside your traces and logs.

Triage and regression detection​

Each issue carries what you need to triage it: a grouped stack trace, first- and last-seen timestamps, an occurrence count and a triage state. A resolved issue that reappears is flagged as a regression, so a fix that quietly breaks again doesn't slip back in unnoticed.

Where it is today​

Error tracking is the youngest module in avuru obs. Derivation from your existing telemetry runs by default; the Sentry ingest port is opt-in. Some things you'd expect from a mature error tracker — deminified JavaScript frames from source maps, release tracking and alerting on new or spiking issues — aren't here yet. Check Feature status for exactly what's live before you rely on it.

Learn more​

• Errors signal — how derivation and Sentry ingest work.
• avuru obs vs. Sentry — derived issues, DSN ingest and no per-event meter.
• avuru obs vs. GlitchTip — the same Sentry protocol, unified with your other signals.

avuru obs is all-in-one observability — traces, metrics, logs and continuous profiling — in a single install, on one storage engine, with zero code changes. eBPF discovers your services; OpenTelemetry carries the detail.

This site is where the onboarding funnel, guides, reference and integrations live. The fastest way in is the 30-second guide: one helm install and the service map lights up.

The docs are open and bilingual (English + French). Found a typo or a gap? Hit "Edit this page" on any doc — it's a three-click pull request from there.