Data model and signals

Diting organizes data around one timeline. Every signal shares timestamps and correlation keys, so pages can hand off to each other.

Six signal types

Signal	Source	Keys
Metrics	Hosts, containers, services, databases	host_id, service, pod
Logs	Files, containers, journald, syslog	host_id, service, trace_id
Traces	eBPF, OTLP	trace_id, span_id
Profiles	Host and runtime sampling	host_id, pid
Sessions	Browser RUM	session_id, trace_id
Database	Protocol parsing	trace_id, instance, statement

Correlation

Three keys tie one request together:

trace_id: the call chain across services and hosts
session_id: the browser session
host_id: the host identity

Traces jump to logs and sessions; sessions jump back to traces and replay. Time range and filters survive the hop.

Write path

agent → gateway → Kafka → collector → ClickHouse. The gateway handles auth and rate limiting, Kafka absorbs spikes, the collector writes columnar data.

Database statement digests use a separate topic, db-query-digests, and land in diting.dwd_db_query_digest.

Retention

Retention is configured per signal. Hot data serves live queries; cold data serves review. The exact window comes from your storage plan.

Clocks

Synchronize NTP before comparing timestamps across hosts. Diting corrects drift, but correction is not a substitute for a real time source.

OTLP

Teams already running OpenTelemetry can send to the gateway's OTLP endpoint without deploying an agent. Both sources share the same correlation keys.