Skip to main content

Store

Trait Store 

Source
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§

Source

fn insert_spans(&self, spans: &[Span]) -> Result<()>

Source

fn query_traces(&self, query: &TraceQuery) -> Result<Vec<Span>>

Source

fn get_trace(&self, trace_id: &str) -> Result<Vec<Span>>

Source

fn list_services(&self) -> Result<Vec<ServiceInfo>>

Source

fn add_comment( &self, trace_id: &str, span_id: Option<&str>, author: &str, body: &str, ) -> Result<TraceComment>

Source

fn get_comments(&self, trace_id: &str) -> Result<Vec<TraceComment>>

Source

fn insert_logs(&self, logs: &[LogRecord]) -> Result<()>

Source

fn query_logs(&self, query: &LogQuery) -> Result<Vec<LogRecord>>

Source

fn insert_metrics(&self, metrics: &[MetricPoint]) -> Result<()>

Source

fn query_metrics(&self, query: &MetricQuery) -> Result<Vec<MetricPoint>>

Source

fn query_summary( &self, last_seconds: i64, service: Option<&str>, ) -> Result<SummaryReport>

Source

fn query_anomalies( &self, current_seconds: i64, baseline_seconds: i64, service: Option<&str>, ) -> Result<AnomalyReport>

Source

fn query_correlate(&self, trace_id: &str) -> Result<Option<CorrelateReport>>

Source

fn query_sql(&self, sql: &str) -> Result<Vec<Value>>

Read-only SQL query surface (SELECT/WITH) over the telemetry tables, returning rows as JSON objects.

Provided Methods§

Source

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.

Source

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.

Source

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".

Implementors§