Skip to content
Ritele
DocsDownload
Product paper · Release 0.0.31November 2026 · Nestrand Technologies Limited

Ritele

rí tẹ́lẹ̀Yorùbá · “to see beforehand”

Your services already describe your architecture in every trace they send. Ritele reads it back to you, and tells you what gives out first.

  • Self-hosted, one container
  • Plain OpenTelemetry in
  • Telemetry stays in your network

Metrics, traces and logs, on a map of what actually runs.

Every feature, in chapter 02 ↓
  • Architecture

    A live system map

    Every service, database, queue, cache and external API, drawn from your traces and always current. Nobody has to draw it.

  • Metrics

    Health for every component

    A plain status with the reading behind it, judged against each component’s own busy-hour usual, with SLOs and alerts.

  • Traces

    Every request, followed

    A waterfall for any kept request, the failing call marked, clock skew corrected, linked to the issue it explains.

  • Logs

    The line that explains it

    Error and warning counts as a health signal, and the lines themselves, stored by Ritele or read from your Loki, each linked to its trace.

  • Sequence diagrams

    How every flow works

    A sequence diagram for every operation each service serves, drawn from real traffic: who calls whom, in what order, and how long it takes.

  • AI Advisor

    Ask why, get evidence

    Ask in plain language. Answers draw on metrics, traces and logs together and cite each one. Off by default; can run on your own model.

  • Capacity

    What gives out first

    Rehearse ×5 traffic, a slower database or one replica fewer. See what saturates first, at what multiple, and how sure Ritele is.

  • Drift

    The diagram, checked

    Import the approved architecture and see every new component, unexpected call and missing dependency. Export the real map for the audit.

Ritele is self-hosted observability built on OpenTelemetry. It draws a team's architecture from the traces their services already emit, puts metrics, traces and logs on that one map, and predicts which component saturates first when traffic grows.

It runs as a single container inside your network, and your telemetry stays there. This paper explains the problem it solves, how it works, what it claims and what it refuses to guess, and how it is deployed, secured and licensed.

The problem

The system architecture diagram is always wrong.

Architecture changes in production. The diagram changes in a wiki, if at all.

A service gains a dependency in a Tuesday deploy. A team adds a cache to get through a busy month. Someone calls a third-party API directly because it was faster than going through the ledger. None of it reaches the diagram.

Observability tools see the running system, but they show it as separate signals: a latency graph, a trace, a log line. They answer “what is this number doing?” well. They answer “what do we run, and what depends on what?” poorly, and that is the question an incident, a capacity plan or an audit begins with.

Ritele starts from structure. Every trace already records which service called which, so Ritele reads the traces, draws the system they describe, and attaches each metric, trace and log line to the component it belongs to.

The product

Everything in Ritele.

One map of what runs, and every feature built on it: architecture, health, investigation, performance and capacity.

What do I run?

The architecture

  • System map

    Services, databases, queues, caches, gateways and external APIs drawn from live traces, grouped by domain and sized by traffic. Callers it cannot name are shown and counted.

    needs service.name

  • Components

    Every component with its type, owner and whether it reports for itself. Set a type, an owner or pin one, and the map keeps it.

    typed by OpenTelemetry conventions

  • How it works

    A sequence diagram for every operation a service serves, drawn from kept traces: the calls it makes, in order, with their timings.

    one per operation

  • Drift

    Import the approved diagram or accept today’s map as intended. New components, unexpected calls, missing dependencies and layer violations are reported against it.

    Structurizr · Mermaid · CSV

  • Snapshots and exports

    See the map as it was at an earlier moment, present it full screen, and export it for the audit file or the repo.

    PNG · SVG · Mermaid · Structurizr

  • Environments

    Production, staging and the rest kept apart, each with its own map, history, intended model and scenarios.

    needs deployment.environment.name

What is wrong right now?

Health and investigation

  • Health

    Healthy, degraded, unhealthy or silent for every component, with the reading that set it beside its usual. An issue opens only once a problem has lasted.

    latency · errors · saturation · runtime

  • Likely source

    One issue for the component that most likely broke, with everything it affects listed under it, so an incident reads as one problem.

    no setup

  • Metrics

    Any component's metrics in plain words, beside what each one means. A service leads with its requests, errors and latency; a database, queue or external API shows the calls made to it.

    p50 · p95 · p99

  • Traces

    A waterfall for any kept request, with the failing call marked, clock differences between hosts corrected, and the keep rate set from Settings.

    tail sampling built in

  • Logs

    Error and warning counts per service as a Health signal. Read the lines from your own Loki, or let Ritele store them masked and searchable, each linked to its trace.

    stored · your Loki · links

  • Infrastructure

    Hosts, containers and pods get a status of their own from a small agent, so a stopped container sits beside the services it hurts.

    hosts · containers · pods

  • Change events

    Deploys and restarts marked on every chart and listed in one place, so “what changed?” is answered before anyone asks.

    needs service.version

  • SLOs

    A budget per service or entry point, previewed against the past before you save it, with burn-rate alerts and a monthly report.

    burn-rate alerts · CSV report

  • Notifications

    Issues and SLO alerts sent where your team already works, one alert per issue, closed when it clears.

    Slack · Teams · PagerDuty · Opsgenie · Alertmanager · webhook · email

  • Advisor

    Ask in plain language. The answer draws on metrics, traces and logs together and cites each one. Off by default, and it can use a model inside your network.

    answers with evidence

What breaks next?

Performance and capacity

  • Paths

    Every entry point with the hop-by-hop path a request takes, the self time at each hop, its share of the total, and how much p99 would fall if that hop got 20% faster.

    critical path · share · leverage

  • Scenarios

    Multiply traffic, slow a dependency, add a replica or remove a component. See what saturates first, at what multiple, with a confidence and a PDF report.

    what-if on real traffic

  • Headroom

    How far each service, database and queue is from its first limit today, with a link to try the change in a scenario.

    concurrency · CPU

  • Shared pool pressure

    The connections a database has in use, summed across every service that calls it, so you see 11 of 15 before the queue backs up at 15.

    needs db.client.connection.*

Running it

Operation and governance

  • One container

    The OpenTelemetry Collector, the analysis and the UI in one image, running as an unprivileged user. Point any SDK or Collector at it.

    OTLP gRPC :4317 · HTTP :4318

  • Two storage tiers

    Embedded storage on a local volume, or your own Postgres and ClickHouse. Same features and behaviour on every plan.

    SQLite + DuckDB · Postgres + ClickHouse

  • Sign-in and roles

    Accounts with viewer, editor and admin roles, or single sign-on through your identity provider with roles from its groups. Viewers read; every change needs a role that allows it.

    on by default · OIDC

  • Coverage

    Settings shows what each service sends and what is missing, from pool metrics to CPU limits, so you know which answers to trust.

    data sources · coverage table

  • Retention and storage

    Choose how long metrics, traces and logs are kept, and see the storage each uses against its cap.

    per signal

  • Offline licence

    Licences are verified locally against keys compiled into the release. Air-gapped installs paste the key in as text.

    Ed25519

Architecture

Plain OpenTelemetry in. A map out.

No proprietary agent and no new protocol. Anything that exports OTLP can send to Ritele.

  1. your side

    SDK or Collector

    Any OpenTelemetry SDK, or your own Collector.

  2. :4317 · :4318

    Bundled Collector

    Counts every span, keeps the traces worth keeping, deletes personal data.

  3. ingest

    Graph builder

    Names and types each component and records what changed.

  4. storage

    Metrics, traces, logs

    Embedded, or your own Postgres and ClickHouse.

  5. :8080

    Analysis and UI

    Health, paths, drift and capacity, in the browser.

Everything after “your side” runs in one container: ritele/ritele

Components are named, never invented

A service is identified by its environment and its service.name, so two processes with the same name are one component. A database, queue or external host is named by its system, such as postgresql:ledger, and appears on the map even if it sends nothing itself.

Types follow the evidence

An explicit ritele.component.type wins, then the OpenTelemetry semantic conventions, then a heuristic, and only then “unknown”. A type a person sets overrides all of these, and a known type is never quietly downgraded.

Gaps are drawn

Traffic from a caller Ritele cannot name is shown as “?” and counted. The map you present is the map you have, gaps included.

Adoption

What it needs from you.

One attribute draws the map. Each one you add unlocks the next capability.

  1. 01The mapspans with service.name on the resource. That is all.
  2. 02Environments kept apartdeployment.environment.name on the resource.
  3. 03Entry points and critical pathshttp.route on server spans (not the raw URL), the messaging conventions on consumers, and a span for every outbound call, so each hop is on the path and none is charged to its caller.
  4. 04Rate, errors and duration you can trusta Collector carrying the spanmetrics and servicegraph connectors.
  5. 05How full things arethe db.client.connection.* metrics from your services.
  6. 06What a change would dorungs 3 to 5, plus a declared concurrency per component.
  7. 07Your own vocabulary on the mapritele.domain, ritele.layer, ritele.zone on the resource.
  8. 08Drift from what you intendedan intended model — accept the current map as intended, or import one from CSV, Mermaid or Structurizr.
  9. 09Health: a status for every component, and whyrequest and runtime metrics from your services, and pool metrics where they hold a pool. See What Health needs.

For Node services, the MIT-licensed @omob/otel-kit sets all of this up with one Telemetry.start() call. It is optional, and every rung can be wired by hand in any language.

In practice

A payments team, an old diagram, an audit on Friday.

On Monday the CTO asks who understands how checkout works, end to end. Here is the week that follows.

Map · Monday · 14:00

By the afternoon, the team can see what actually runs.

Nobody can answer the CTO’s question from the old diagram. Tunde points OpenTelemetry at Ritele instead.

  • Ritele draws services, databases, queues, caches, gateways and external APIs from live traces, grouped by domain and sized by traffic.
  • When traffic comes from a caller it can’t identify, Ritele marks it “?” and counts it. It doesn’t guess.

Metrics · Tuesday · 09:46

The worst problem is at the top of the list.

Checkout slows down, and the cause isn’t on the diagram.

  • Every component has a status, with the numbers behind it and the signals it was judged from.
  • Each issue shows when it started, which entry points it hurts, and the deploys around it.

Traces + Logs · Tuesday · 09:49

One request, followed to the line that explains it.

Three minutes later, Tunde opens one of the slow checkouts.

  • The trace shows the request crossing each service, with the failing call highlighted.
  • Ritele reads matching lines from your own Loki on demand, masked and audited. Each trace_id links back to the trace.

Advisor · Tuesday · 10:05

One answer, with the evidence attached.

Before writing the incident note, Tunde asks one question.

  • The Advisor answers from metrics, traces and logs together, and names the components on the map.
  • It’s off by default. Point it at a model inside your network and nothing leaves.

Prediction · Thursday · 14:00

What gives out first at ×5?

The fix shipped on Tuesday. Next month’s launch should bring five times the traffic.

  • Describe the change, and Ritele lists what fills up, in order, at what multiple and why.
  • Each answer states how confident it is. In simulator tests across 15 system shapes, it was never late on what gives out first.

Map · Friday · 09:00

The auditors get the architecture that actually runs.

The CTO’s question finally gets an answer.

  • Import the approved diagram as Structurizr, Mermaid or CSV, and Ritele flags new components and unexpected dependencies.
  • Export the observed map as PNG, SVG, Mermaid or Structurizr for the audit file.

Prediction

Seeing beforehand, without guessing.

Ritele predicts only from limits it knows. Anything it cannot know, it names.

A scenario multiplies traffic at an entry point, slows a dependency, adds a replica or removes a component. Ritele carries the change down the real call paths from kept traces and the real request rates from metrics, then compares each component's load with the limit it holds.

An unknown limit is not judged

If nobody declared, stated or measured a component's concurrency, it is left out of the saturation order and listed as an unknown limit, with the requests in flight it would need to handle.

A queue that never drains gets no number

Once load reaches a limit, waiting time grows without bound. Ritele reports that component as not draining and gives no latency figure for it.

Unexplained traffic is reported

Calls that no traced path explains are listed as untraced traffic, so you know the load exists even though it cannot be costed.

In simulator tests across 15 system shapes, it was never late on what gives out first. Every answer states how confident it is and what data it used.

Method

Numbers that hold up.

Every status and figure should survive the question “where did that come from?”

  • Every request is counted

    Rates and durations come from metrics built on every span before sampling. Keeping 1% of traces does not mean seeing 1% of traffic.

  • A p99 is never one request

    With fewer than 300 requests in a window, Ritele reports what the slowest three exceeded, in words.

    “The slowest 3 of 114 requests took 2 s or more”

  • Usual means busy hours

    A service is compared with hours busy enough to judge, weighted by traffic, so a quiet night does not set what is normal.

  • Probes are not users

    Health and readiness routes are left out of Health, so a load balancer's polling cannot set a service's latency.

  • A caller's mistake is not a failure

    A 4xx a service returns does not count against it. A 5xx or a 429 does.

  • Clocks are corrected, openly

    When a host's clock runs ahead of its caller's, its spans are moved inside the call that waited on them, and the trace says so.

Security

Where your data stays.

Ritele runs on your servers. Your telemetry leaves only where an admin sends it; one daily install report is on by default, and one setting stops it.

  1. R-01Telemetry stays in your network
  2. R-02Single-tenant, your infrastructure
  3. R-03Licences verify offline
  4. R-04A datastore credential only where you put one
  5. R-05Architecture review ships switched off
  6. R-06One line a day, documented
  7. R-07One signing key, and a record of every licence
  8. R-08Trace data stays put
  9. R-09People sign in, and each has a role
  10. R-10Notifications go only where an admin points them
  11. R-11Log lines are stored only where an admin chooses
  12. R-12Known personal-data attributes are removed before anything is stored
  13. R-13Three published ports
  14. R-14Passwords and sessions
  15. R-15Single sign-on goes only to your identity provider

Personal data is removed on arrival: the bundled Collector deletes enduser.* and user.* attributes and request and response headers. Database statements are stored with values masked, and connection strings are never stored. Sign-in is on by default, with per-user roles on every change, and can go through your own identity provider.

Every requirement in full →What the daily install report carries →

Deployment

Running it.

One command, no account. Point OpenTelemetry at it and open the UI.

docker run -p 4317:4317 -p 4318:4318 -p 8080:8080 -v ./data:/data ritele/ritele
  • 4317OTLP over gRPC
  • 4318OTLP over HTTP
  • 8080The UI and its API
Small estates

Embedded storage

SQLite and DuckDB on a local volume, sized from the container's own memory and CPU limits.

Larger estates

Postgres and ClickHouse

Your own databases for more history. Both tiers pass the same contract tests and behave the same.

Commercial

Licensing and what is next.

Start free. One licence per organisation when you outgrow it, with no per-seat pricing and no usage metering.

The free plan has no time limit. Paid plans add environments, services and features. Both storage tiers come with every plan: a licence limits what is on the map, not where it is stored. A service counts once per service.name; databases, queues, caches and external APIs are not counted.

Current limits and prices →Every release, and what changed →

Planned, not in this release

Planned, not in this release
PlannedUntil then
A Helm chart for the agentKubernetes manifests for kustomize, a Compose file and a systemd unit run the agent, and Settings › Data sources generates the command for Docker, Kubernetes and a Linux VM.
Kubernetes nodes, workloads and Kafka clusters judged for healthThey appear under Health › Infrastructure with their readings but have no checks of their own yet. A node shows its host's status, a workload is read through its pods, and Kafka readings count towards the topic's checks.
Colophon

Ritele by Nestrand Technologies Limited, RC 9834714.

Describes release 0.0.31, November 2026. The payments team and its figures are illustrative; product behaviour is as documented in the docs.