glossary · what the words mean

Observability, OpenTelemetry and architecture terms, in plain words.

Each term has a general definition first, then what it means in Ritele.

Observability

How well you can tell what a system is doing, and why, from the signals it emits — usually metrics, traces and logs — without shipping new code to ask a new question.

In Ritele: Metrics, traces and logs are joined on one map of the components that actually run.

OpenTelemetry

An open standard and set of SDKs, maintained under the CNCF, for producing and sending traces, metrics and logs in one vendor-neutral format.

In Ritele: Ritele reads only OpenTelemetry. Any SDK in any language works, with no Ritele library in your services.

OTLP

The OpenTelemetry Protocol: how telemetry travels from an SDK or Collector to a backend, over gRPC (conventionally port 4317) or HTTP (port 4318).

In Ritele: The container accepts OTLP on both ports, and serves the UI on 8080.

Trace

The record of one request as it moves through a system: a tree of spans that share a trace id, from the first service it reached to the last call it caused.

In Ritele: Traces draw the map, and the kept ones are what Paths and the trace view are built from.

Span

One timed operation inside a trace — a request handled, a query run, a message published — with a start, a duration, a kind (server, client, producer, consumer or internal) and attributes.

In Ritele: A client span and the server span it reached become one edge on the map.

Resource and service.name

A resource describes what produced the telemetry: the service, its version, where it runs. service.name is the one resource attribute every service should set.

In Ritele: service.name is a component's identity within its environment: two processes with the same name are one component.

Semantic conventions

OpenTelemetry's agreed attribute names, such as http.route, db.system and messaging.system, so that every SDK describes the same thing the same way.

In Ritele: Components are typed from them: a database, a cache, a queue or an external API, not just a box.

OpenTelemetry Collector

A vendor-neutral service that receives telemetry, processes it — filtering, sampling, deriving metrics — and exports it to one or more backends.

In Ritele: A Collector is bundled inside the container. You can also keep your own and add one exporter to it.

Service graph

A graph of which services call which, derived by pairing client and server spans. The Collector's servicegraph connector computes one as metrics.

In Ritele: The bundled Collector runs servicegraph, and its output is one of the sources of the map's edges.

Service map

A picture of a system's components and the calls between them, drawn from telemetry rather than by hand. Also called a dependency map or a live architecture diagram.

In Ritele: The system map, grouped into domains and kept current as you ship.

Rate, errors and duration

The three request metrics most worth watching on any service: how many requests, how many failed, and how long they took. Often called RED.

In Ritele: Counted from every span by the Collector's spanmetrics connector, before any sampling.

Tail sampling

Deciding whether to keep a trace after it has finished, so the decision can depend on what happened — keeping every error, for instance — rather than on a coin toss at the start.

In Ritele: Every error and every trace marked for documentation is kept, plus 1% of the rest by default.

Critical path

The chain of operations in a request that the end-to-end time actually waits on. Speeding up anything off it does not make the request faster.

In Ritele: Paths shows it per entry point, with the self time at each hop.

Self time

The part of a span's duration not spent waiting on its children: the time that operation itself cost.

In Ritele: Paths shows each hop's p99 self time, and can rank the hops by what 20% off it would save.

Architecture drift

The gap between the architecture a team intended and the one that runs: calls nobody planned, dependencies that disappeared, components that appeared.

In Ritele: Drift findings are reported against an intended model you import or accept from the current map. The intended model and drift triage need a paid plan.

Saturation

How full a constrained resource is — connections in a pool, depth of a queue, CPU against its limit. A resource near its limit fails before its latency looks wrong.

In Ritele: Pool use is summed across every service sharing a database, not reported per caller.

Loki

Grafana's log aggregation system, which indexes labels rather than the full text of each line.

In Ritele: The Logs page reads lines from your Loki once an admin connects it, and stores none of them. A line with a trace id opens its trace when that trace was kept.