Tracing
What tracing is
One record per request, at a privacy level you choose.
CarbonForge tracing emits one record per completed request, produced by the scheduler inside the serving engine. A trace answers, per request: when it arrived, how long it queued, how long it took end to end, how many tokens went in and out, and how the scheduler treated it.
What traces are for:
- Capacity planning: queue wait and end-to-end latency under your real traffic, not a benchmark's.
- Workload replay: a captured trace can regenerate statistically faithful traffic for tuning and regression runs.
- Accounting: per-request token counts from the engine itself.
The two levels
| Level | Contents | Safe for |
|---|---|---|
standard | Timings, token counts, scheduler metadata. No message content. | Production |
full | Everything in standard plus the raw prompt and output text | Development and workload capture only |
There is also off, the default: nothing is emitted.
Where tracing runs, per pathway
- Self-hosted container: tracing is off by default and entirely yours. Records go only to sinks you configure: a JSONL file on your log volume, an OpenTelemetry collector you name, or both. Nothing is sent to CarbonForge. Enabling it is covered in Container tracing.
- API endpoint: tracing is operated by CarbonForge on the serving side; there is nothing to configure. The record shape is the same, which is what makes workloads comparable across the two pathways.
Record shape in one line
{"request_id": "...", "t_arrival": ..., "t_completion": ..., "prompt_tokens": ...,
"output_tokens": ..., "e2e_latency_s": ..., "ttft_s": null, "queue_wait_s": ...,
"scheduler_family": "...", "priority_score": ...}ttft_s is currently always null: first-token time is not visible to
the scheduler, so the record covers whole-request timing only, for
streaming and non-streaming requests alike. The
standard page documents every field.