Langdock agents can be monitored by Dunetrace with zero code changes. Langdock natively emits OpenTelemetry traces — point its "Tracing cloud URL" at the Dunetrace ingest service and 34 structural detectors activate immediately.

Path 1 — OTel receiver (zero-code monitoring)

How it works

Langdock emits OTLP/HTTP spans for every assistant execution. Dunetrace's ingest service accepts those spans at POST /v1/otlp/traces and maps them to its event model:

Langdock span	Dunetrace events
Root assistant execution span	`run.started` + `run.completed` / `run.errored`
LLM call span (`gen_ai.*` attributes)	`llm.called` + `llm.responded` (model, tokens, latency)
Tool call span	`tool.called` + `tool.responded` (success, latency)
Retrieval span	`retrieval.called` + `retrieval.responded` (result count)

Prerequisites

Dunetrace running locally (docker compose up -d)
A Langdock workspace with admin access
ngrok installed for local testing

Step 1: Verify Dunetrace is running

curl http://localhost:8001/health
# → {"status":"ok","version":"0.5.0"}

/health is liveness only — it makes no database round-trip, so it never fails while the process is serving HTTP. To check that ingest can actually do its job (database reachable, schema at the version this build needs), use the readiness probe instead; it answers 503 until both hold:

curl http://localhost:8001/ready
# → {"status":"ok","version":"0.5.0","db":"ok","schema_version":13,"required":13,"pool":{...}}
#   (schema_version/required track the shared migration count and rise over time;
#    what matters is that they match and the status is "ok")

Step 2: Expose the ingest service publicly

Langdock is a cloud service — its trace exporter sends spans from Langdock's servers, not from your browser. localhost:8001 is not reachable from Langdock. You need a publicly accessible URL.

ngrok http 8001

ngrok will print something like:

Forwarding  https://abc123.ngrok-free.app → http://localhost:8001

Copy that URL — you'll need it in step 4.

ℹ

The free ngrok tier generates a new URL every time you restart it. For production, deploy Dunetrace behind a TLS-terminating reverse proxy with a fixed public hostname and skip ngrok entirely.

Step 3: Verify the endpoint is reachable

curl -X POST https://abc123.ngrok-free.app/v1/otlp/traces \
  -H "Content-Type: application/json" \
  -d '{"resourceSpans":[]}'
# → {}

Step 4: Configure Langdock

In Langdock:

Workspace Settings → Assistants settings
→ Enable "Allow assistant logs"  (toggle on)
→ Tracing cloud URL: https://abc123.ngrok-free.app/v1/otlp/traces
→ Save

The bundled docker compose setup sets AUTH_MODE=dev, so no API key or Authorization header is needed for local testing. The services themselves default to AUTH_MODE=prod — authentication is only skipped when dev mode is set explicitly, so a deployment that doesn't set it requires a key.

Step 5: Run any Langdock assistant

Trigger any assistant execution, then check the ingest service logs:

docker compose logs ingest --tail=20

You should see:

OTLP traces received. resources=1 spans=4 batch_id=...
OTLP persisted. batch_id=... events=6 inserted=6

Step 6: Check the dashboard

Open http://localhost:3000 — the Langdock assistant appears as an agent under its service.name. Detectors run within ~5 seconds of the run completing.

What you get

34 structural detectors run on every Langdock execution without any code change
Slack / webhook alerts fire when failure patterns are detected
Dashboard shows run timelines, token usage, wasted cost per failure
Weekly digest summarizes systemic patterns across all your Langdock assistants

Path 2 — MCP server (in-assistant signal querying)

The Dunetrace MCP server exposes agent monitoring data as tools that any MCP-capable client can call. Langdock supports MCP servers — once connected, a Langdock assistant can query its own Dunetrace signals mid-conversation.

Install the MCP server

cd packages/mcp-server
pip install -e .

Run with SSE transport

dunetrace-mcp --sse --port 8000   # binds 127.0.0.1 only

Configure the environment:

DUNETRACE_API_URL=http://localhost:8002   # Customer API
DUNETRACE_API_KEY=dt_dev_test            # Bearer token

Connect in Langdock

Add the MCP server endpoint in Langdock's MCP configuration. Point it at:

https://your-proxy-host/sse

Langdock is hosted, so it cannot reach a loopback port — and the SSE server has no authentication of its own, so do not simply bind it to 0.0.0.0. Put an authenticating reverse proxy in front, keep dunetrace-mcp on loopback behind it, and give Langdock the proxy URL. Leave DUNETRACE_MCP_READONLY at its default (true) unless you intend a hosted assistant to write policies.

See MCP server docs for the full list of available tools.

Troubleshooting

No runs appearing in the dashboard

Check ingest service logs for OTLP traces received — if absent, Langdock is not reaching the endpoint
Confirm "Allow assistant logs" is enabled in Langdock settings
Run curl -X POST http://localhost:8001/v1/otlp/traces -H 'Content-Type: application/json' -d '{"resourceSpans":[]}' — should return {}

Agent ID shows as `unknown-agent`

Langdock may not set service.name in the resource attributes. Use the X-Dunetrace-Agent-Id header override if Langdock allows custom trace headers, or set a fixed agent_id in Langdock's OTel resource configuration.

Runs appear but no signals

The detector worker polls every 5 seconds; wait up to 10 seconds after the run appears
Check detector logs: docker compose logs detector --tail=50

Langdock