Skip to content

Ritele beside Jaeger, Grafana Tempo and Loki: what each is for.

Most teams that look for an architecture view already run something for traces and logs. This page says plainly what those tools do, what Ritele adds, and where you should keep what you have.

Updated

Jaeger

Jaeger is an open-source distributed tracing platform and a graduated CNCF project. It stores traces, lets you search them, and shows each one as a timeline; it can also draw a service dependency graph from the traces it holds.

Ritele answers a different first question. Its map types each component — database, cache, queue, external API — from the semantic conventions, groups them into domains, shows the traffic on every line, and gives every component a health status from its own metrics. It adds what a trace store does not set out to do: drift from an intended model, the critical path per entry point, and what-if scenarios. The map, Health and tracing are on the free plan; the intended model, drift triage and running what-if scenarios need a paid plan.

Grafana, Tempo and Loki

Grafana Tempo is a trace backend, and with its metrics generator Grafana can show a service graph built from trace data. Loki stores logs. Grafana is where many teams already build dashboards and alerts over all of it.

Ritele works with that rather than around it. Its Logs page reads the lines from your Loki, once an admin connects it. A line that carries a trace id opens that request's trace when tail sampling kept it, and a log link can open the same query in your Grafana. Nothing is copied out of Loki.

Structurizr, Mermaid and hand-drawn diagrams

Diagrams as code, such as Structurizr's C4 models and Mermaid flowcharts, are versioned and reviewable, but someone still has to write down what runs. Drawing tools are quicker to start and quicker to go stale.

On a paid plan, Ritele reads a Structurizr DSL or Mermaid file, or a CSV of edges, as the intended architecture and reports where the running system differs. It also exports what runs as Mermaid or Structurizr DSL, so a diagram in your repository can start from the truth.

When to keep what you have

If you need every trace kept and searchable, keep your trace backend. Ritele keeps every error, every trace marked for documentation and a sampled share of the rest, which is what its map, paths and health need, not a full archive.

Running both is one exporter: add a second OTLP exporter to the Collector you already have, pointed at the container, and your existing pipeline is untouched.