Vyrtel 0.1.1 · open source · MIT

View. Trace.
Understand.

Developer-friendly observability: launch one ~11 MB binary, send it logs, traces and metrics, and start asking questions. Small, fast, light, and everything included.

$ docker run -p 8080:8080 -v vyrtel-data:/data ghcr.io/rowan-smith/vyrtel:latest
11 MBone binary, web UI included
~20 MBmemory when idle
10k/sevents ingested on a laptop
0external services to run

Why Vyrtel

Everything you need. Nothing you have to run.

A complete observability stack that starts in a second and fits on the smallest server you have.

Developer friendly

Launch and send. Run ./vyrtel, POST JSON or point OpenTelemetry at it, and search what arrives. No schema, no setup wizard, no agents to configure.

Small

One ~11 MB binary with the web UI built in, and one data directory. Copy it anywhere, or run the Docker image.

Fast

10,000 events per second on a laptop. Indexes, Bloom filters and time ranges let queries skip most of the data before reading it.

Light

About 20 MB of memory when idle, with a memory limit you set. Compressed segments keep the disk footprint small.

Full featured

The whole stack in the box, sharing one query language.

LogsLive tailTracesMetricsDashboardsAlerts + webhooksOpenTelemetryAPI keysQuery diagnostics

Scalable & distributed Roadmap

Today Vyrtel is a single node that scales with its machine. Planned for 0.3: separate Ingest nodes forwarding to one Core owner, followed by operational hardening. Standalone query roles, storage sharding and replication remain discovery work.

How it works

From a symptom to the cause, in one place.

Logs, traces and metrics live in the same process and the same query language, so the path from “something is wrong” to “this is why” is a few clicks, not a few tools.

01

View.

Search structured events with a small query language, watch them arrive with live tail, and open any event vertically: properties, exception, stack trace.

level = "Error" and service = "payments"
02

Trace.

Jump from a log line to its trace. The waterfall shows which span was slow or failed, with every related log right underneath.

traceId = "4bf92f3577b34da6…"
03

Understand.

Put metrics and log counts on a dashboard, alert when a threshold is crossed, and see exactly how each query used the indexes.

count > 100 in 5 min → webhook

The product

A UI that explains itself.

Dark, dense and fast. Every screen below is the real app, captured by its end-to-end tests.

localhost:8080
Logs view: query bar, filter panel with detected fields, query diagnostics and an expanded error event with properties.
Query, filter by detected fields, and see exactly which indexes each search used.

Everything in the box

One binary. The whole stack.

OpenTelemetry

OTLP/HTTP in

Point any OpenTelemetry SDK or Collector at it. Logs, traces and metrics, protobuf or JSON, gzip.

Traces

Waterfall + related logs

Search traces by status, duration or service; inspect spans; navigate logs ↔ traces both ways.

Metrics

Counters, gauges, histograms

Sum, count, min, max, avg and last with group-by, plotted over any time range.

Dashboards

Panels on a grid

Log counts, metric lines, single stats and saved queries side by side.

Alerts

Thresholds that page you

Log-count alerts with OK / FIRING / ERROR state, history and webhook delivery.

Storage

Crash-safe by design

Append-only WAL with checksums, immutable zstd segments, bitmap indexes, Bloom filters and zone maps. Bounded memory, automatic recovery.

Operations

Boring in production

Per-signal retention, compaction, strict or normal durability, API keys, admin login, health endpoints and a non-root Docker image.

Query language

Ask production a question.

Small enough to learn in a minute, precise enough for incidents. Fields come from your events, nested paths included, and every query reports what it scanned and which indexes it skipped with.

Query language reference →

queries
# errors from one service
level = "Error" and service = "payments"

# nested fields, comparisons, negation
http.statusCode >= 500 and not environment = "staging"

# slow requests
durationMs > 500

# level ranges and grouping
level >= Warning and (service = "orders" or service = "payments")

# free text
"timed out"
✓ 21 results · 274 µs · 3/4 segments skipped by index · 0 B read
vyrtel
$ ./vyrtel
Vyrtel 0.1.1

Web UI              http://localhost:8080
Data directory      ./data
OTLP HTTP           http://0.0.0.0:8080/v1/*
Memory limit        512 MB
Durability          normal

Ready.

$ curl localhost:8080/api/v1/events \
    -H 'content-type: application/json' \
    -d '{"level":"Error","service":"payments",
         "message":"Payment failed"}'
{"accepted":1}

Quiet when healthy

Running in one command.

No setup wizard, no connection strings, no cluster to plan. Start the binary, open the URL it prints, and send events over HTTP or OTLP.

  • Point OpenTelemetry at OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:8080
  • Or POST JSON / NDJSON to /api/v1/events
  • Everything persistent lives in one directory

Why Vyrtel

Observability shouldn't need more resources than what it observes.

A typical stack

  • Search cluster for logs
  • Time-series database for metrics
  • Tracing backend + its storage
  • Message queue in front of it all
  • Dashboards and alerting service

Several services, several gigabytes of RAM, before the first log line.

Vyrtel

HTTP API · OTLP ingestion · query engine · storage · metadata · web UI · background jobs

One process, one data directory, idle at ~20 MB.

Download

Get Vyrtel 0.1.1

Single self-contained binaries with the web UI built in. Download, run, open the printed URL.

Docker

docker pull ghcr.io/rowan-smith/vyrtel:latest
docker run -p 8080:8080 -v vyrtel-data:/data ghcr.io/rowan-smith/vyrtel:latest

Multi-arch (amd64, arm64), distroless, runs as non-root.

Linux / macOS

chmod +x vyrtel-* && ./vyrtel-*

Verify downloads against SHA256SUMS.

From source

cargo run --release -p server

Needs Rust stable and Node 22. Build guide.

See what production is doing.