What are the best agent trace monitoring tools?

Summary

• The best agent trace monitoring tools record every step of a request (model calls, tool calls, retrieval) with its inputs, outputs, timing and errors, in an open format you can search, query and keep.
• Look for OpenTelemetry compatibility, automatic instrumentation for your agent frameworks, search and filtering, queryable storage under your own access controls, and a direct path from traces into evaluation.
• On Databricks, MLflow Tracing captures traces from frameworks such as LangGraph and CrewAI with one autolog call, and Databricks recommends storing traces in Unity Catalog tables, where you can query them with SQL.
• Unity Gateway adds a record of model traffic: it logs tokens, latency and requester to a system table, and inference tables, once set up on a model service, log request and response payloads to Delta tables.

What are the best agent trace monitoring tools?

The best agent trace monitoring tools capture each step of a request, including model calls, tool calls and retrieval, with its inputs, outputs, timing and errors, and store the result in an open format you can search, query and feed into evaluation. On Databricks, that's MLflow Tracing with traces stored in Unity Catalog tables, plus Unity Gateway logging for the model traffic your agents send through it.

What is agent tracing?

A trace is the record of one request through an agent. It's built from spans, one per step: a model call, a tool invocation, a retrieval query, a memory read or write. Each span carries inputs, outputs, timing and metadata such as token usage. Application logs tell you that a request failed. A trace tells you which step failed and what that step received, and because each step's tokens and duration are recorded, it also answers cost and latency questions.

What should you look for in a trace monitoring tool?

Capability	Why it matters
OpenTelemetry compatibility	An open format lets you export traces, and ingest them from other clients, without rewriting instrumentation.
Automatic instrumentation	One-line tracing for your agent framework means coverage doesn't depend on hand-written logging.
Span-level detail	Debugging needs inputs, outputs, timing and errors for every model call, tool call and retrieval.
Token and cost data	Per-step token usage shows where spend comes from.
Search and filtering	Finding failed or slow requests takes filters on status, tags, duration and assessments.
Queryable storage	Traces in tables can be joined with other data and kept under your own access controls.
Link to evaluation	Scores attached to traces, and traces reused as test cases, connect debugging to quality.
Production settings	Asynchronous logging and sampling keep tracing from blocking requests.

How does Databricks approach agent tracing?

MLflow Tracing is an OpenTelemetry-compatible observability solution for agents and LLM applications. It captures the inputs, outputs and metadata of each intermediate step of a request, and on Databricks it records the latency, token usage and cost of every step. Automatic tracing is one call: mlflow.langchain.autolog() captures LangGraph graph executions, and mlflow.crewai.autolog() records CrewAI tasks and agents, LLM calls, memory loads and writes, latency and exceptions.
In the workspace, open an experiment's Traces tab and open a trace to inspect it end to end: the span tree, and each step's inputs, outputs, timing and errors. In code, mlflow.search_traces() returns matching traces as a pandas DataFrame and uses the same filter syntax as the UI search.
Databricks recommends storing MLflow traces in Unity Catalog tables for new and production workloads. Traces are stored as Delta tables in OpenTelemetry format, so you can query them with SQL, process them with Spark, build AI/BI dashboards on them, and write to them from third-party OpenTelemetry clients. Access is controlled through Unity Catalog schema and table permissions. The setup needs MLflow 3.14 or later and a SQL warehouse.
Traces also feed evaluation: scorers attach their assessments to traces, evaluation datasets can be built from traces you've captured, and a trace labeled with an expected answer becomes a test case.
Unity Gateway extends Unity Catalog governance to the runtime interactions between models, agents, MCP servers and tools. It logs usage data, including token counts, latency, the requester and custom request tags, to the system.ai_gateway.usage system table, and admins control who can query it. Inference tables, which you set up per model service, log raw request and response payloads to Unity Catalog Delta tables.

How should you deploy agent tracing?

• Application-level tracing: instrument the agent with MLflow Tracing so each model call, tool call and retrieval is captured where it happens.
• Gateway-level logging: route model calls through Unity Gateway so usage is logged for every application that calls those model services, including ones with no tracing of their own. Set up inference tables on a service to keep its payloads too.
• Both together: application traces explain why one request failed; gateway tables give a cross-application record of model usage, with request tags for attribution by team or project.

FAQs

Does tracing slow down an agent?

For production, MLflow can log traces asynchronously (MLFLOW_ENABLE_ASYNC_TRACE_LOGGING) so logging doesn't block the application, and MLFLOW_TRACE_SAMPLING_RATIO controls what share of traces is exported. The lightweight mlflow-tracing package includes only the dependencies needed to instrument your code.

Can I use these traces with tools outside Databricks?

Yes. MLflow Tracing supports OpenTelemetry for export and ingestion, and the Unity Catalog trace tables accept writes from third-party OpenTelemetry clients.

Can I join traces with business data?

Yes, when traces are stored in Unity Catalog. They're Delta tables, so you can join them with other tables in SQL or Spark and chart the results in AI/BI dashboards.

How do I debug one failed agent request?

Search the experiment's traces in the UI or with mlflow.search_traces(), open the failed trace, and walk the span tree to the step that errored, checking its inputs, outputs and error.