Architecture

LeanSignal’s architecture exists to break one loop and replace it with another. Understanding the two loops explains every component that follows.

The pain cycle

Traditional observability is supply-driven: store everything, get the bill, prune reactively, repeat. Watch where the data flows — and where it doesn’t:

The Observability Pain Cycle High bills drive the telemetry filtering.

• Telemetry Data Flow
• Control Flow

Three things to notice:

• The telemetry stream is dense the whole way. The agent has a filter, but it forwards everything by default — so everything collected is everything stored, and the cost meter sits at 4–5 out of 5.
• The red arrow runs backwards. The store drives the analysis tools: whatever you happened to collect dictates what you are able to ask afterwards. There is no notion of demand anywhere in the loop.
• The control loop barely exists. Config changes are rare, manual, after-the-fact tweaks — usually triggered by a bill.

Cost grows with data volume, not with the value you get from it. Teams end up choosing between two bad options: keep everything and pay for noise, or whitelist blindly and lose signal they didn’t know they’d need.

The value cycle

LeanSignal inverts the loop. Demand — the metrics your dashboards and alerts actually depend on — governs the pipeline:

The Observability Value Cycle Value drives the telemetry filtering.

• Telemetry Data Flow
• Control Flow

The same three places, transformed:

• Dense in, sparse out. The filter forwards nothing by default. Your workloads still emit everything, but only the demanded subset crosses into central storage — the cost meter sits at 1–2 out of 5.
• The green arrow runs forwards. Demands drive the store: what you asked for is what gets kept. Every stored signal is tied to the need it serves — the cost–value link.
• The control loop is alive. You define demands (or dashboards and alerts that imply them), and they continuously configure the agent’s filter. New cost only ever comes from new need.

The components that implement it

Your workloads (OpenTelemetry SDKs and collectors)
   │  OTLP metrics
   ▼
LeanSignal Agent — gateway, one per cluster or environment
   ├─ stores everything ────────► co-located VictoriaMetrics
   │                              (full fidelity, one-day retention)
   ├─ forwards the demanded ────► central dataplane
   │  subset only                 (what dashboards and alerts query)
   └─ gRPC control stream ◄─────► LeanSignal app
      (outbound only, TLS)        demand set down · metric index up

The app

The app is where operators work:

• Define demands, build dashboards, and configure alerts — or import all three at once from the integrations catalog.
• Manage agents and users.
• Resolve everything that consumes metrics into a single demand set and push it to every connected agent.

Whenever something that consumes metrics changes — a panel query, an alert rule, a demand — the app recomputes the demand set and broadcasts the update over the control stream, so agents adjust in near real time.

The agent

The agent is a custom OpenTelemetry Collector distribution that runs at the edge, one per cluster or environment. Its pipeline:

1. Receive OTLP telemetry — metrics, logs, and traces — from your workloads (plus its own host’s metrics).
2. Index every timeseries it sees and report that index to the app — this is how LeanSignal knows what could be collected, not only what is.
3. Store everything in its co-located VictoriaMetrics, at full fidelity, for one day.
4. Filter what it forwards: only timeseries in the current demand set are remote-written to your central dataplane.

The agent maintains a single long-lived gRPC stream to LeanSignal, dialed outbound on port 443 over TLS — no inbound connectivity is ever required. Demand-set updates arrive on that stream, and the agent reports its status and collection counters back on it.

Two tiers of storage

The split is what makes the value cycle practical rather than a blind whitelist:

• At the edge — the agent’s local VictoriaMetrics holds everything for a fixed one-day window. When you edit a dashboard, preview queries are answered from this store, so you can explore and chart metrics before they are part of any demand. Full local fidelity means declaring demand never requires guessing what exists.
• In the dataplane — your central, long-term store receives only the demanded subset. This is what dashboards render from and what alert rules are evaluated against, and it is the only tier whose volume you pay to keep.

Logs and traces follow the same pattern

Every signal runs the same store-everything-locally, forward-only-demand pipeline. At the edge, the agent keeps metrics in its co-located VictoriaMetrics (one day), logs in a co-located Loki (roughly one hour), and traces in a co-located Tempo (roughly one hour). Demanded log streams and trace services are pushed directly to your tenant’s central log and trace stores, exactly as demanded metrics are remote-written to the metrics dataplane. Central retention is 30 days for all three signals. See Logs and Traces.

Standards, not lock-in

Both ends of the pipeline are open standards: OpenTelemetry in (OTLP from any SDK or collector, plus the full Contrib receiver set for scraping) and PromQL out (dashboards and alerts query Prometheus-style against VictoriaMetrics). The agent itself is open-source software you can read, audit, and run yourself — adopting the demand-driven model doesn’t mean adopting a proprietary agent.

Data residency

Telemetry is processed and stored within the European Union, in line with the GDPR. See Security & data residency for the full picture.

Tip

New to the model? Start with Demand-driven observability.