SDK Overview
Upblit SDKs automatically instrument your HTTP applications to emit distributed traces and structured logs — with minimal code changes.
Available SDKs
| SDK | Language | Status | Package |
|---|---|---|---|
| Express SDK | Node.js | Stable (v2.0.0) | upblit-express |
| Go SDK | Go | Stable | github.com/upblit/go-sdk |
| Python SDK | Python | Stable | upblit (PyPI) |
| Java SDK | Java | Coming Soon | — |
| React SDK | TypeScript | Coming Soon | — |
How SDKs Work
Every SDK follows the same pattern:
- Middleware intercepts every incoming HTTP request
- A
traceIdand rootspanIdare generated and stored in async-local/thread-local context - Your app code runs normally
- Span helpers (
service(),call(),controller()) create child spans - On response: the root span is pushed to an in-memory buffer
- Every 30 seconds (configurable): the buffer is flushed to
POST /ingest/tracesandPOST /ingest/logs
Span Naming Convention
All SDKs use a type:name prefix for span names:
| Prefix | Meaning | Example |
|---|---|---|
controller: | HTTP handler | controller:POST |
service: | Internal service call | service:getUserById |
external: | Outbound HTTP call | external:stripe |
Ingest Endpoint
All SDKs send data to:
POST https://ingest.upblit.com/ingest/traces
POST https://ingest.upblit.com/ingest/logs
Header: x-api-key: <your-api-key>Buffering Behavior
- Traces and logs are buffered in memory separately
- Default flush interval: 30 seconds
- On flush failure: the batch is re-queued (no data loss)
fatallog level: flushed immediately (not buffered)- On shutdown (
close()): remaining buffer is flushed before exit
Last updated on