What is an OTLP backend?

An OTLP backend is any service that receives telemetry over the OpenTelemetry Protocol (OTLP), stores it, and lets you query it. Because OTLP is a standard wire format — not a vendor SDK — you can move between backends by changing environment variables, not code.

The protocol, briefly

OpenTelemetry defines OTLP for shipping three signal types: traces (spans and events), logs, and metrics. It runs over two transports — OTLP/HTTP with protobuf payloads, and OTLP/gRPC. A backend that speaks OTLP accepts both; the exporter in your app (or an OpenTelemetry Collector in front of it) does the encoding, batching, and retries.

Point any instrumentation at an endpoint

The exporter is configured entirely by the standard OpenTelemetry environment variables. There is no backend-specific SDK to add and nothing to fork:

export OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.example.com
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_HEADERS="x-simpletel-team=<your-team-id>"
export OTEL_SERVICE_NAME=my-app

Anything that exports OTLP works this way: the auto-instrumentation agents (Java, Python, Node, Go, .NET), a hand-instrumented SDK, or an OpenTelemetry Collector whose exporters block points at the endpoint. The collector path is the common one in production — apps send to a local collector, the collector exports to the backend.

A runnable example with simpletel

simpletel is an OTLP backend in a single binary. This is the whole setup — install, sign in, create a team, and export the standard variables in one line:

curl -fsSL https://simpletel.dev/install | sh
simpletel login                        # GitHub sign-in
simpletel team create --name my-app    # mint a team + ingest key
eval "$(simpletel env)"                # sets OTEL_EXPORTER_OTLP_* (upstream only)
simpletel run -- echo hi               # smoke test: lands a cli.run trace
simpletel get traces                   # terminal-first read path

After eval "$(simpletel env)" your app is already exporting to simpletel through the standard variables shown above — simpletel run just wraps a command to include the smoke-test span and prove the pipe end to end. There is no simpletel SDK and no exporter fork.

What to look for when choosing one

Lock-in. If the backend needs a proprietary SDK or an agent you cannot point anywhere else, you have coupled your instrumentation to it. Upstream-OTLP-only means switching backends is two environment variables. simpletel takes only upstream OTLP.

Metering unit. Backends bill per gigabyte, per host, per seat, or per record — and the unit decides who gets surprised. Per-GB punishes verbose payloads; per-host and per-seat punish growth. simpletel meters one unit: a record (one span, one log record, or one metric data point), the same unit the rate limiter counts.

Spend caps. A meter with no ceiling is a bill-shock vector. Look for a hard cap enforced by the server, not a dashboard alert. simpletel hard-stops ingest at the plan cap by default (2× the included allowance on paid plans, raisable to 3×).

Retention. Almost every vendor gates retention harder than volume — the free tiers are 14–30 days. Decide what window you actually need before you optimize price. simpletel's free tier is 7 days on purpose; paid plans are 30 and 90 days.

Self-hosting. simpletel is one Go binary and one SQLite file. You can run the whole backend on a single small VM — no cluster, no object store, no external database — with Litestream replicating the file for durability. The honest tradeoff: single-VM economics mean a single writer (SQLite WAL) and roughly a billion records a month per node; beyond that you need dedicated capacity. If you want a horizontal cluster out of the box, a distributed backend is the better fit.