Agent-Ready Observability

Logs, metrics, and traces, built on S3

High-performance, extremely low-cost observability for the era of software abundance. Don’t sacrifice on performance, cost, or flexibility.

Book a demo Read the docs

plural-telemetry · prod-use1● 3 stores healthy

STORESPEAKSMEDIAN QUERY · PEER → OURS

Plural Logsreplaces LokiLogQLLoki push · OTLP · Elasticsearch _bulk9.2 ms → 6.1 ms

Plural Metricsreplaces Prometheus / MimirPromQLPrometheus remote write · OTLP4.6 ms → 1.8 ms

Plural Tracesreplaces TempoTraceQLOTLP · Zipkin20.9 ms → 3.9 ms

s3://acme-telemetryGrafana compatibleApache 2.0

Rust rewrites

The stack you already run, without the operational toil

Re-instrumenting is a non-starter, so each store speaks the protocols and query languages you already use. Point your agents and Grafana at a new URL and keep everything else.

Logs, replacing Loki

Accepts Loki push, OTLP, and Elasticsearch _bulk, and answers LogQL through Loki’s HTTP API.

Metrics, replacing Prometheus

Takes Prometheus remote write and OTLP, and answers PromQL with the same API Grafana already uses.

Traces, replacing Tempo

Ingests OTLP and Zipkin, with trace-by-id lookups and TraceQL search on Tempo’s endpoints.

One engine underneath

Every store is built on SlateDB, an LSM tree that writes straight to S3, GCS, or Azure Blob with an NVMe cache in front.

Faster and vastly simpler

A writer, a stateless reader, and a bucket

The Grafana stack is nine interlocking services, hash rings, and replicated disks. Tuning it and owning it in production is out of reach for most teams. Plural Telemetry is writers in front of object storage and stateless readers that use local disk only as a cache, so scaling up means adding pods.

Architecture, side by side

Plural Logswriters + stateless readers on S3

Grafana Lokimicroservices mode

Illustrative sizing at 5 TB/day, from vendor capacity guides. Not benchmark results.

~50%

lower query latency on average vs Loki, Mimir, and Tempo

5×

faster median trace query than Tempo

1/18

of Mimir’s CPU for the same workload

replicated disks, hash rings, or ZooKeeper to run

Fuzz tested

Fuzzed against the real thing

Prometheus, Loki, and Tempo are the executable spec. Every store is tested against its reference implementation on identical data and queries, so compatibility and speed are measured together rather than claimed separately.

How we test

Oracle regression tests

Every pull request sends identical fixtures and queries to Plural Telemetry and to Prometheus, Loki, or Tempo, then compares the responses.

Nightly differential fuzzing

Randomized datasets and recursively generated queries probe Unicode, NaN, clock skew, cardinality extremes, and out-of-order writes. Every run is seeded and replayable.

Published benchmarks

The same runs record latency, CPU, and memory on both sides, with the seed and commit, including the cases where we lose.

Query latency from the published runs

Median and tail latency for each store against its peer, both on an S3 backend:

Query latency, peer versus Plural Telemetry
Store	Peer	Peer p50	Plural p50	Peer p99	Plural p99
Plural Logs	Loki	9.2 ms	6.1 ms	497.6 ms	216.4 ms
Plural Metrics	Mimir	4.6 ms	1.8 ms	81.4 ms	22.1 ms
Plural Traces	Tempo	20.9 ms	3.9 ms	159.8 ms	66.6 ms

Prometheus serving small queries from local disk is faster at the median; its tail latency is similar to ours.

Runs anywhere

Deploy to any Kubernetes cluster with the operator

Install one Helm chart, then declare each database as a custom resource. The operator runs it in your cluster, against your own bucket, and handles rolling restarts, scaling, and volume resizing.

Metrics, Logs, and Traces custom resources, plus per-tenant credentials
Writers, per-shard readers, Services, PDBs, autoscalers, and Ingress
S3, GCS, or Azure Blob, with IRSA, Pod Identity, or workload identity
Standalone mode for dev and edge, sharded mode for production

Installation guide

install

helm upgrade --install telemetry-operator \ oci://ghcr.io/pluralsh/charts/telemetry-operator \ --namespace telemetry --create-namespace

telemetry/logs.yaml

apiVersion: telemetry.plural.sh/v1alpha1

kind: Logs

metadata:

name: logs

namespace: telemetry

spec:

mode: Sharded # or Standalone for dev and edge

config:

retention: 14d

storage:

objectStore:

type: Aws # or Gcp, Azure

aws:

region: us-east-1

bucket: acme-telemetry

writer:

replicas: 3

reader:

autoscaling:

enabled: true

Agent-ready

Agents are the new primary consumer of telemetry

Agents don’t need a dashboard. They need a fast, programmable API over the raw data. Every store answers over plain HTTP, with namespaced multi-tenancy and per-namespace auth, so each agent sees only the telemetry it should.

Observability is a core integration point for Plural’s workbenches, so investigations run against your own data, in your own cluster.

workbench · incident-triage

GET /read/ns/payments/loki/api/v1/query_range ?query=sum by (route) (rate({app="payments-api"} |= "error" [5m])) &start=now-1h Authorization: Bearer <scoped JWT>

Cost breakdown

What 5 TB/day of logs actually costs

Compare Plural Telemetry with self-hosted Loki and Datadog. Every assumption is adjustable.

All assumptions

Monthly cost of log ingestion

Ingest5.0 TB/day

Retention15 days

Avg event650 B

Compression8×

Peak / avg1.5×

vCPU-hour$0.041

Plural Telemetry$2,284/mo

3 writers × 8 vCPU + 3 reader groups × 2 × 2 vCPU

Grafana Loki$6,920/mo

129 vCPU across 9 components, 17 ingesters3.0× Plural Telemetry

Datadog$413k/mo

234B events/month180.7× Plural Telemetry

Plural Telemetry

Compute 24 writer + 12 reader vCPU	$1,072
Object storage 10,313 GB incl. index	$237
Object requests WAL, SST, compaction, cache misses	$510
Cross-AZ traffic write forwarding + query fan-out	$464

Grafana Loki

Compute 129 vCPU (66 in RF=3 ingesters)	$3,842
Object storage 9,656 GB chunks + index	$222
Object requests chunk flushes, query fetches	$693
Cross-AZ traffic replication to 3 ingesters	$2,027
WAL volumes 17 × 100 GB gp3	$136

Datadog

Ingestion $0.10 / GB ingested	$15k
Indexing $1.70 / M events, 15-day retention	$398k

Estimates for comparison only, using AWS us-east-1 on-demand prices and Datadog list prices with an annual commitment. They exclude engineering time, Datadog Flex Logs, and committed-use discounts.

Datadog

Priced per event indexed

At 5 TB/day, indexing is about 96% of the bill, and it scales with event count, not bytes.

Loki

Replication and sprawl

Every write fans out to three ingesters across zones, which costs about $2,000/month in cross-AZ traffic alone at 5 TB/day.

Plural Telemetry

Write once, let S3 keep it

Each record goes to one shard owner, and object storage provides the durability. Readers only move query results between zones.

Questions

Do I have to re-instrument anything?

No. Each store speaks the protocols you already send, including Prometheus remote write, Loki push, OTLP, and Zipkin, and answers PromQL, LogQL, and TraceQL through the APIs Grafana already queries. Switching is a change of URL.

What happens when a writer dies?

Its Kubernetes Lease expires, another writer takes it over, and the shard is reopened from object storage. Data is durable once it lands in the bucket; writes can wait for that before acknowledging.

How do you know it’s compatible and fast?

Every store is continuously fuzzed against its reference implementation on identical data and queries, with latency, CPU, and memory recorded for both sides and published, including the cases where we lose.

Is it open source?

Yes. Plural Telemetry is Apache 2.0, runs entirely in your cluster against your own bucket, and is developed in the open by Plural.

Observability that’s cheap and boring

See Plural Telemetry and agents working on your own clusters in a 30-minute demo.

Book a demo