Traces and logs with OpenTelemetry

Errors tell you that something broke. Traces show the path one request took — which service called which, what each step cost — and logs show what your code said along the way. Belvador takes both from the standard OpenTelemetry SDKs your services may already use, over OTLP/HTTP, and keeps them on your own node next to your errors.

What you get#

• Traces — a list of traces and spans with a time histogram, filters by project, environment, service and time, and a waterfall of every span in one trace with its attributes and events.

• Logs — search by text, service, environment, severity or trace id, and open the lines written just before and after one line.

• Links to errors — an issue shows Logs around this error: the logs of the error's trace when the error carries a trace id, otherwise the same project and environment around that moment. An error event and the trace it happened in share a trace id, so you can move between them.

• Connection evidence — the project's Connection tab lists which services sent traces or logs, with which SDK, and when last.

What it is not#

• Metrics are opt-in. Belvador stores OTLP metrics (one point a minute) when you turn them on — see Metrics. The standard variables leave them off.

• No browser tracing. Ingest keys are secret: send traces and logs from servers, workers and the Collector, never from code that runs in a browser.

• No full APM. There are no service maps, profiling or session replay. Traces and logs are kept for debugging, for a limited time (see Sampling and cost).

Tested runtimes#

Belvador runs a real application on each runtime below against a complete local copy of its pipeline (edge, relay, node and storage) and reads every span and log back. A runtime is marked tested only when that run passes: one trace with a server and a client span, one log line with the right severity and the request's trace id, no secret from the request stored, exporter retry after a 503, and — on the reference runtime — wrong key rejected, two minutes with the node offline without loss, and an app that keeps answering when Belvador is unreachable.

Other languages (.NET, Ruby, PHP, Rust, Bun) work the same way — any OpenTelemetry SDK that exports OTLP/HTTP reads the same variables — but Belvador has not run them, so they are not marked tested.

Where the data lives#

Spans and log records are stored only on your workspace's node. Belvador's edge receives each OTLP request over TLS, checks the key and limits, and passes it to your node; if the node is offline, the request waits at the edge encrypted to your node's key — for up to 15 minutes for traces and logs — and is delivered when it reconnects. Belvador's own database keeps only metadata: which services and SDKs sent data, counts and sizes per signal, and connection check receipts.

One tracing owner#

Run one tracing setup per process. If a process already has OpenTelemetry, add Belvador as an exporter target with the variables from the quickstart — do not add a second SDK that also creates spans. The Belvador SDKs (@belvador/*) are errors-only: they never create spans, and with the otel option they attach the active OpenTelemetry span's ids to each error so the error and the trace line up (see Link requests).

Next#

1. Send your first traces and logs.

2. Pick your runtime: Node.js, Python, Go, Java, Deno, or forward everything through the Collector.

3. Read Privacy before turning on extra instrumentation.