OpenTelemetry traces and logs, stored next to your errors

The short answer#

• Send traces and logs with the standard OpenTelemetry SDKs or the Collector over OTLP/HTTP.

• They are stored on your node next to your errors, and an issue opens its trace and the logs around it.

• Authenticate with a bvi_ ingest key that can only send data.

• No metrics, no browser tracing and no full APM.

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.

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

• Errors linked to both. An error event that carries a trace id opens its trace with the failing span highlighted, and its logs.

• Connection evidence. The project's Connection tab lists which services sent traces or logs, with which SDK and when last (OpenTelemetry overview).

Setup is the standard exporter#

Create an ingest key (it starts with bvi_, is shown once and can only send data), then point the OTLP exporter at Belvador with the standard environment variables:

export OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.belvador.dev/otlp/<project-id>export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobufexport OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20<your-ingest-key>export OTEL_TRACES_EXPORTER=otlpexport OTEL_LOGS_EXPORTER=otlpexport OTEL_METRICS_EXPORTER=noneexport OTEL_SERVICE_NAME=my-serviceexport OTEL_RESOURCE_ATTRIBUTES=deployment.environment.name=production

No Belvador package is needed for traces and logs. Runtime guides: Node.js, Python, Go, Java, Collector — or start with the quickstart.

Tested runtimes#

"Tested" means we ran that SDK version against Belvador and read the data back. The OTLP endpoint answers 200 once the edge has durably accepted a batch; the node can still drop rows over its limits, and the usage page shows those drops (OTLP reference).

Keeping volume in check#

During the beta a workspace can store 5 GB of traces and 5 GB of logs a month, kept 7 days. Sampling at the SDK or Collector is the main control; the guide has settings that keep errors' traces while dropping routine ones (sampling and cost). Measured throughput is on the benchmarks page.

What it is not#

• No metrics. OTLP metrics are refused; set OTEL_METRICS_EXPORTER=none.

• No browser tracing. Ingest keys are secrets; send from servers, workers and the Collector only.

• No full APM. No service maps, profiling or session replay. Traces and logs are kept for debugging for a limited time.

• OTLP/HTTP only, protobuf or JSON.

Questions#

Do I need to drop Sentry to use OpenTelemetry?#

No. Keep the Sentry SDK for errors and add OpenTelemetry for traces and logs; with the bridge, errors carry the active span's trace id (Sentry and OpenTelemetry).

Where are traces stored?#

On your node, like errors. While the node is unreachable, the edge holds batches sealed to your node's key.