kopai/otel-instrumentation
Instrument applications with the OpenTelemetry SDK and prove the telemetry is good by validating it against a local Kopai backend. Use when setting up observability, adding tracing/logging/metrics, deciding what to instrument or which attributes to add, retrofitting OTel into an existing codebase, threading context through call chains, configuring sampling, or when traces/logs/metrics aren't appearing after setup. Also use when users say things like "my traces aren't showing up", "I don't see any data", or "how do I add observability to my app". Do NOT use to investigate existing telemetry for a root cause (use root-cause-analysis), to build dashboards (use create-dashboard), or to instrument LLM and agent calls (use otel-genai-instrumentation).
—
—
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
setup-backend.mdreferences/
| title | impact | tags |
|---|---|---|
| Start Kopai Backend | CRITICAL | setup, backend, collector |
Start Kopai Backend
npx @kopai/app startStarts two things, on two ports that are easy to confuse:
| Port | Service | Direction |
|---|---|---|
| 4318 | OTEL collector | Your app sends telemetry here (OTLP/HTTP) |
| 8000 | API server | The CLI and SDK read data from here |
Pointing OTEL_EXPORTER_OTLP_ENDPOINT at 8000 is the most common setup mistake —
see troubleshoot-wrong-port.md.
Confirm it is up
curl -s -o /dev/null -w '%{http_code}\n' -X POST http://localhost:4318/v1/traces \
-H 'Content-Type: application/json' -d '{"resourceSpans":[]}'A 2xx means the collector is accepting OTLP. This is step 1 of the workflow, and every later assertion depends on it — do not proceed past a non-2xx here.
Reference
https://github.com/kopai-app/kopai-mono/tree/main/packages/app
references