OTLP connection check: prove traces and logs reach the right project

"Data shows up in Traces" tells you something arrives; it does not tell you which key, project and environment it came through. The OTLP connection check proves one path end to end and leaves a receipt on your node.

What the Connection tab shows#

Open the project and go to Connection. Pick the environment at the top; everything below is judged for that environment only.

Evidence per signal has one row each for errors, check-ins, traces and logs. A signal is judged only by its own evidence — verified traces never mark errors as connected.

Services seen lists each service that sent traces or logs, with its language and SDK. Those come from the service's own resource attributes (service.name, telemetry.sdk.*): self-reported, not a certification.

Run the check#

1. On Connection, choose the environment, then Check the OTLP connection.

2. Belvador shows a curl command with a fresh marker (bv1_ followed by 32 hex characters). It sends one span and one log, both carrying the attribute belvador.verification_id and the chosen environment.

3. Replace the key placeholder with an ingest key that has Traces and Logs and allows that environment, and run the command from a machine that can reach the internet — ideally the one your service runs on, so the check also proves its network path.

4. Keep the page open. The steps turn done one by one: Sent from your machine → Belvador's edge accepted it → Your node stored the receipt → Read back from your node, separately for traces and logs.

The check waits 10 minutes. If nothing arrives, the panel says so; start again for a new marker.

Run it from your own SDK#

Instead of curl, put the marker on one span or one log record from your service. The attribute must be on the span or log record itself, not on the resource:

import { trace } from "@opentelemetry/api";trace.getActiveSpan()?.setAttribute("belvador.verification_id", "bv1_…");

from opentelemetry import tracetrace.get_current_span().set_attribute("belvador.verification_id", "bv1_…")

This proves more than curl: your service's own exporter, configuration and network reached the node. Remove the line afterwards.

What a passing check proves#

That this key, for this project and environment, reached your node at that moment, and that the node could be read back. It does not certify a runtime, prove that every service is instrumented, or keep proving anything later — a revoked key or a changed deployment is not noticed until records stop. The status stays Verified after a check; Quiet for 24 h+ is what tells you records stopped.

When a step stays waiting#

More symptoms: Troubleshooting.