Building a telemetry API
in under 10 minutes
The useful version starts smaller than most observability projects: accept events, store them, and show them.
The first useful OpenTrace API is not complicated. It needs one endpoint that receives telemetry, a storage model that preserves events, and a dashboard that can group those events by collection or process. Everything else can grow from that core.
The implementation starts with a simple HTTP contract. A script or worker sends a type, label, value, payload, collection, and timestamp. The server authenticates the request, normalises the fields it understands, appends the event, and makes it available to the live view.
Keep the write path boring
Telemetry clients should not need a complex SDK before they can report progress. A plain HTTP call is enough. That choice matters because the best instrumentation often lives in scripts, one-off jobs, and worker processes where dependency weight is a real cost.
Start with useful event types
OpenTrace centres on progress, metrics, notes, JSON payloads, durations, and milestones. Those types cover most status-reporting needs without turning the API into a general-purpose analytics platform.
The 10-minute version
Build the endpoint. Append events. Render the latest state by collection. Run it with docker compose up -d --build. Then instrument one real job. If the dashboard answers a real operational question, the architecture has earned its next layer.