Skip to main content
By default, runLocal() automatically sends spans to Tracia in the background. This gives you observability without blocking your application.

How Tracing Works

  1. runLocal() completes the LLM call
  2. Returns the result immediately
  3. Submits the span to Tracia in the background
  4. Retries failed span submissions automatically

Span Metadata

Add metadata to help filter and analyze spans:

Span Fields

Custom Span ID

Provide your own span ID for correlation with external systems:
Custom span IDs must match the format: sp_ followed by exactly 16 hexadecimal characters (e.g., sp_1234567890abcdef).

Waiting for Spans

Use flush() to wait for all pending spans before shutdown:

Graceful Shutdown

Error Handling

onSpanError Callback

Handle span submission failures without affecting your main application:

Retry Behavior

Span submissions are automatically retried:
  • Up to 2 retry attempts
  • Exponential backoff (500ms, 1000ms)
  • onSpanError called only after all retries fail

Disabling Tracing

Disable tracing for specific requests:
Use cases for disabling tracing:
  • Development and testing
  • Sensitive data that shouldn’t be logged
  • High-volume, low-value requests
  • Reducing costs on non-critical paths

Viewing Spans

Access spans in the Tracia dashboard or via the SDK:

Span Storage

Spans include:
  • Full input messages (after variable interpolation)
  • Original variables (for filtering)
  • Complete output text
  • Token usage and latency
  • LLM configuration (temperature, maxOutputTokens, topP)
Spans are stored securely and retained according to your plan’s data retention policy.