Databricks MLflow Tracing
Use this skill for MLflow observability and tracing workflows on Databricks.
Read databricks-core first for CLI authentication, profile selection, and
workspace discovery.
On Databricks, reuse the existing experiment ID or choose an absolute workspace
path such as /Users/<email>/my-experiment or /Shared/my-experiment; relative
names in the bundled onboarding examples are for non-Databricks tracking servers.
Read the matching guide directly:
| Request | Read this guide |
|---|---|
| Choose a use case or get started with MLflow | MLflow onboarding |
| Instrument an app or agent and verify tracing | MLflow tracing |
| Retrieve traces by ID, time, status, or metadata | Retrieve traces |
| Inspect one trace or explain an agent failure | Analyze a trace |
| Reconstruct or debug a multi-turn chat session | Analyze a chat session |
| Query token, latency, or quality metrics on a supported OSS MLflow server | Query MLflow metrics |
For agent evaluation, scorer creation, or implementing a fix after diagnosis,
use databricks-mlflow-evaluation.
For work that spans multiple guides, use this order:
- Determine the use case with MLflow onboarding.
- Add or verify tracing with MLflow tracing.
- Retrieve traces before trace or chat-session analysis.
- Use Query MLflow metrics for aggregate trends.
For Databricks trace storage, read the tracing guide's Databricks reference before claiming that traces use Unity Catalog storage.
For a Unity Catalog trace location, verify the deployed identity rather than a
local user. It needs experiment access, CAN USE on the SQL warehouse,
USE CATALOG and USE SCHEMA, and explicit MODIFY, SELECT on each generated
spans, logs, metrics, and annotations table. ALL PRIVILEGES alone does not
satisfy those table grants. Confirm persistence by reading back a fresh trace
written under the deployed identity.
