Skip to main content
While tracing setup automatically logs LLM calls, you often need to trace additional application logic like data retrieval, preprocessing, business logic, or tool invocations. Custom tracing lets you capture these operations.

Trace function calls

Braintrust SDKs provide tools to trace function execution and capture inputs, outputs, and errors:
  • Python SDK uses the @traced decorator to automatically wrap functions
  • TypeScript SDK uses wrapTraced() to create traced function wrappers
  • Go SDK uses OpenTelemetry’s manual span management with tracer.Start() and span.End()
All approaches achieve the same result—capturing function-level observability—but with different ergonomics suited to each language’s idioms.
The traced function automatically creates a span with:
  • Function name as the span name
  • Function arguments as input
  • Return value as output
  • Any errors that occur

Add metadata and tags

Enrich spans with custom metadata and tags to make them easier to filter and analyze.
Tags from all spans in a trace are aggregated together at the trace level and automatically merged (union) rather than replaced.
Store any value you filter, group, or sort on as a top-level metadata or span_attributes field, rather than embedding it inside input or output. This includes IDs like transactionId and categoricals like environment or tenant_id. Filters and aggregations are more efficient against structured fields than against values nested in input or output. See Filter on structured fields, not blob contents.

Within a span

Attach metadata and tags from within the function body. This is useful for data that’s only available during execution, like computed values or results from intermediate steps.
  • In TypeScript and Python, use span.log().
  • In Go, C#, Ruby, and Java, use the OTel setAttribute API. Custom attributes appear in the span’s metadata field. Use braintrust.tags for tags. For LLM-specific OTel attributes, see OpenTelemetry.

At span creation

The TypeScript and Python SDKs support passing metadata and tags at span creation time, which avoids a separate span.log() call. This is useful at request entry points where you have request-scoped data — like a user ID or org ID — already available and don’t want to thread it through helper functions.

Manual spans

For more control, create spans manually using logger.traced() or startSpan():
Span names must always be strings. Passing non-string values will cause validation failures. See Troubleshooting for details.

Nest spans

Spans automatically nest when called within other spans, creating a hierarchy that represents your application’s execution flow:
This nesting makes it easy to see which operations happened as part of a larger workflow.

Troubleshooting

If you pass a non-string value (like an object or array) to the name field of a span, your logs will not appear in the UI - they will be hidden due to schema validation failure. Span names must always be strings.Before passing a value to the name parameter in tracing functions, ensure it is a string:
If spans aren’t reaching Braintrust or instrumentation isn’t wrapping clients as expected, enable the SDK’s internal debug logging to see what’s happening under the hood. This surfaces flush failures, API retry attempts, and instrumentation lifecycle events.Set the BRAINTRUST_DEBUG_LOG_LEVEL environment variable:
Or configure it programmatically:
Log levels from least to most verbose: "error", "warn", "info", "debug". This only affects local console output and does not change what data is logged to Braintrust.

Next steps