pub trait Store: Send + Sync {
Show 17 methods
// Required methods
fn insert_spans(&self, spans: &[Span]) -> Result<()>;
fn query_traces(&self, query: &TraceQuery) -> Result<Vec<Span>>;
fn get_trace(&self, trace_id: &str) -> Result<Vec<Span>>;
fn list_services(&self) -> Result<Vec<ServiceInfo>>;
fn add_comment(
&self,
trace_id: &str,
span_id: Option<&str>,
author: &str,
body: &str,
) -> Result<TraceComment>;
fn get_comments(&self, trace_id: &str) -> Result<Vec<TraceComment>>;
fn insert_logs(&self, logs: &[LogRecord]) -> Result<()>;
fn query_logs(&self, query: &LogQuery) -> Result<Vec<LogRecord>>;
fn insert_metrics(&self, metrics: &[MetricPoint]) -> Result<()>;
fn query_metrics(&self, query: &MetricQuery) -> Result<Vec<MetricPoint>>;
fn query_summary(
&self,
last_seconds: i64,
service: Option<&str>,
) -> Result<SummaryReport>;
fn query_anomalies(
&self,
current_seconds: i64,
baseline_seconds: i64,
service: Option<&str>,
) -> Result<AnomalyReport>;
fn query_correlate(&self, trace_id: &str) -> Result<Option<CorrelateReport>>;
fn query_sql(&self, sql: &str) -> Result<Vec<Value>>;
// Provided methods
fn health(&self) -> Result<()> { ... }
fn flush(&self) -> Result<()> { ... }
fn apply_framed_wal(&self, _framed: &[u8]) -> Result<()> { ... }
}Expand description
Storage backend for all telemetry signals. The server depends on
Arc<dyn Store>, so backends (DuckDB today, TaelBackend next) are
swappable without touching the API, ingest, or query layers.
Synchronous by design — see docs/tael-backend-impl-plan.md, Phase 0.
Send + Sync so it can be shared as Arc<dyn Store> across tokio tasks and
held in axum state.
Required Methods§
fn insert_spans(&self, spans: &[Span]) -> Result<()>
fn query_traces(&self, query: &TraceQuery) -> Result<Vec<Span>>
fn get_trace(&self, trace_id: &str) -> Result<Vec<Span>>
fn list_services(&self) -> Result<Vec<ServiceInfo>>
fn add_comment( &self, trace_id: &str, span_id: Option<&str>, author: &str, body: &str, ) -> Result<TraceComment>
fn get_comments(&self, trace_id: &str) -> Result<Vec<TraceComment>>
fn insert_logs(&self, logs: &[LogRecord]) -> Result<()>
fn query_logs(&self, query: &LogQuery) -> Result<Vec<LogRecord>>
fn insert_metrics(&self, metrics: &[MetricPoint]) -> Result<()>
fn query_metrics(&self, query: &MetricQuery) -> Result<Vec<MetricPoint>>
fn query_summary( &self, last_seconds: i64, service: Option<&str>, ) -> Result<SummaryReport>
fn query_anomalies( &self, current_seconds: i64, baseline_seconds: i64, service: Option<&str>, ) -> Result<AnomalyReport>
fn query_correlate(&self, trace_id: &str) -> Result<Option<CorrelateReport>>
Provided Methods§
Sourcefn health(&self) -> Result<()>
fn health(&self) -> Result<()>
Readiness probe — Ok(()) when this store can serve requests. Backs the
REST /readyz endpoint (docs/tael-server-scaling-ha.md §5.4). The
default is Ok(()): an embedded backend that constructed successfully
and holds its file locks is, by definition, ready. Backends that depend
on the network (e.g. RemoteStore, FanoutStore)
override this to probe their dependencies.
Sourcefn flush(&self) -> Result<()>
fn flush(&self) -> Result<()>
Flush durable buffered state ahead of a graceful shutdown. The WAL fsync on the write path is the real durability boundary, so this is best-effort: it tightens the hot tier’s on-disk state so a restart or standby replays less WAL (§5.4 “flush the hot tier”). Default is a no-op.
Sourcefn apply_framed_wal(&self, _framed: &[u8]) -> Result<()>
fn apply_framed_wal(&self, _framed: &[u8]) -> Result<()>
Standby entrypoint for WAL replication: durably accept a framed WAL
record shipped from a leader and bring local state up to it
(docs/tael-server-scaling-ha.md §5.1). Backs the
POST /internal/wal/records endpoint. Default: rejected — only the
tael-backend engine, which owns a WAL, can act as a standby.
Dyn Compatibility§
This trait is dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety".