Skip to main content
Baseten’s Truss server includes built-in OpenTelemetry (OTEL) instrumentation. Export these traces to any OTLP-compatible collector, including collectors that forward data to Datadog, Honeycomb, or another observability provider. Tracing helps diagnose prediction latency and performance bottlenecks. It can add request overhead, so it is disabled by default.
This page covers traces from Dedicated Inference deployments that use the Truss server. It does not configure Model API telemetry or export Model API billing data.

Export built-in traces with OTLP

Send Truss’s built-in spans to an OpenTelemetry Collector or another OTLP/HTTP endpoint:
  1. Configure an OTLP/HTTP receiver that the deployment can reach. For example, use an OpenTelemetry Collector that exports data to your observability provider. To send traces to Datadog, configure the collector with the Datadog exporter.
  2. Set the receiver’s full trace endpoint in config.yaml and enable tracing:
    config.yaml
  3. Send requests with a traceparent header to continue an existing distributed trace. If you omit the header, Truss generates a trace ID.
OTEL_EXPORTER_OTLP_ENDPOINT must contain the complete OTLP/HTTP trace endpoint. Include /v1/traces when your collector uses the standard OTLP path.
Do not place authentication credentials in environment_variables. If your provider requires credentials, send traces through a collector that stores them securely, or use the secret-backed Honeycomb configuration below.

Export built-in traces to Honeycomb

Truss has a dedicated Honeycomb configuration that reads the API key from Baseten secrets:
  1. Add your Honeycomb API key to Baseten secrets as HONEYCOMB_API_KEY.
  2. Update config.yaml:
    config.yaml
  3. Send requests with a traceparent header to continue an existing distributed trace. If you omit the header, Truss generates a trace ID.

Add custom OTEL instrumentation

Use the OpenTelemetry packages included with the Truss server to create custom spans and events. The following example sends custom spans to an OTLP/HTTP collector:
model.py
Truss isolates its built-in trace context from custom instrumentation. Custom spans use the provider that your model configures and do not become children of Truss’s internal spans.