Status:v0.1.0Latest release v0.1.0,

Tayga

OpenTelemetry traces and logs turned into error stories with root cause and critical path.

License
AGPLv3, Enterprise on request
Built with
Rust, ClickHouse, Redpanda
Install
One-line installer or Helm chart
The Tayga Stories page: KPI tiles, the story groups with their trends, and the inspector for the selected group with its request path and waterfall.
Stories, one group per problem, captured from a running stack with the OpenTelemetry demo on 7 Oct 2026.

The problem

When a request fails across your services, OpenTelemetry gives you every span and every log line, and leaves the reading to you: find the span that broke, work out what normal looks like for that endpoint, dig out the logs that matter. Repeats of one problem show up as hundreds of separate traces.

How it works

How Tayga turns OpenTelemetry data into an error story
  1. OTLP: Traces and logs over gRPC or HTTP
  2. Redpanda: Keyed by trace id, so a trace stays together
  3. Assembler: Closes a trace after 10 s quiet, 60 s at most
  4. ClickHouse: Raw spans and logs, stories and templates
  5. Error story: Root cause, critical path, baseline diff

What it does

Error and slow stories
Every assembled trace is checked. A failing request, or one slower than max(p99 × 1.5, p99 + 100 ms) of its endpoint's baseline, becomes a story.
Deterministic root cause
Fixed rules over the span tree, no LLM: the same input gives the same answer, in a sentence such as “checkout could not reach payment”, with the critical path.
Comparison with normal
Operations that are new, missing or slower than in the endpoint's baseline from the last hour.
Story groups
A fingerprint of the kind, endpoint, root-cause span and masked message folds repeats into one group with a trend.
Log templates and alerts
Drain mines each service's logs at ingest. New templates, rate spikes and, when you ask for it, silence raise alerts, delivered to webhooks and Slack.
Service map and pipeline health
Rate, error ratio and p99 per service against its 24-hour baseline, and throughput and consumer lag for Tayga itself, without Prometheus.

Try it

curl -fsSL https://raw.githubusercontent.com/softberries/tayga/master/scripts/install.sh | sh

Explained before you open it

Tayga analyses traces as they stream in. tayga-ingest receives OTLP and publishes one record per trace id to Redpanda, keyed by trace id, so every span of a trace lands on the same partition. The assembler closes a trace after 10 s without new spans (60 s at most), builds the span tree, and turns failing and slow requests into stories with a root cause, a critical path and a baseline diff. By the time you open Tayga, the failing requests are already explained.

The installer runs Tayga, ClickHouse and Redpanda on one host with Docker Compose; any OpenTelemetry Collector connects with one exporter. For Kubernetes there is a Helm chart.

Where it fits, honestly

Tayga is a focused tool. It does not ingest OTel metrics, so for dashboards you build yourself Grafana and Prometheus sit next to it. Its root cause is always a span, so infrastructure failures are out of reach. It is young, and has been tested against the OpenTelemetry demo. It can run alongside your existing stack: it takes OTLP from the same Collector, and its trace view links out to Jaeger.

The core is AGPLv3. Tayga Enterprise, with SSO, multi-tenancy, high availability and support, is available on request under a commercial license, priced per cluster or node rather than per GB.

Writing about Tayga