Skip to main content

Observability overview

Mastra's observability system gives you visibility into every agent run, workflow step, tool call, and model interaction. It captures three complementary signals that work together to help you understand what your application is doing and why.

  • Tracing: Records every operation as a hierarchical timeline of spans, capturing inputs, outputs, token usage, and timing.
  • Logging: Forwards structured log entries from your application and Mastra internals to observability storage, correlated to traces automatically.
  • Metrics: Extracts duration, token usage, and cost data from traces automatically, with no additional instrumentation required.

When to use observability
Direct link to When to use observability

  • Debug unexpected agent behavior by inspecting the full decision path, tool calls, and model responses.
  • Monitor latency across agents, workflows, and tools to identify bottlenecks.
  • Track token consumption and estimated cost over time to control spending.
  • Diagnose workflow failures by tracing execution through each step.
  • Compare agent performance before and after prompt or model changes.

How the pieces fit together
Direct link to How the pieces fit together

Tracing is the foundation. When observability is configured, every agent run, workflow execution, tool call, and model interaction produces a span. Spans are organized into traces that show the full request lifecycle as a hierarchical timeline.

Metrics are derived from traces automatically. When a span ends, Mastra extracts duration, token counts, and cost estimates without any extra code. These metrics power the dashboards in Studio.

Logs are correlated to traces automatically. Every logger.info(), logger.warn(), or logger.error() call within a traced context is tagged with the current trace and span IDs. You can navigate from a log entry directly to the trace that produced it.

All three signals share correlation IDs (trace ID, span ID, entity type, entity name), so you can jump between a metric spike, the traces behind it, and the logs within those traces.

Get started
Direct link to Get started

Install @mastra/observability and a storage backend:

npm install @mastra/observability @mastra/libsql @mastra/duckdb

Then configure observability in your Mastra instance. The following example uses composite storage to route observability data to DuckDB (which supports metrics aggregation) while keeping everything else in LibSQL:

src/mastra/index.ts
import { Mastra } from '@mastra/core/mastra'
import { LibSQLStore } from '@mastra/libsql'
import { DuckDBStore } from '@mastra/duckdb'
import { MastraCompositeStore } from '@mastra/core/storage'
import {
  Observability,
  DefaultExporter,
  CloudExporter,
  SensitiveDataFilter,
} from '@mastra/observability'

export const mastra = new Mastra({
  storage: new MastraCompositeStore({
    id: 'composite-storage',
    default: new LibSQLStore({
      id: 'mastra-storage',
      url: 'file:./mastra.db',
    }),
    domains: {
      observability: await new DuckDBStore().getStore('observability'),
    },
  }),
  observability: new Observability({
    configs: {
      default: {
        serviceName: 'mastra',
        exporters: [
          new DefaultExporter(), // Persists traces to storage for Mastra Studio
          new CloudExporter(), // Sends observability data to hosted Mastra Studio (if MASTRA_CLOUD_ACCESS_TOKEN is set)
        ],
        spanOutputProcessors: [
          new SensitiveDataFilter(), // Redacts sensitive data like passwords, tokens, keys
        ],
      },
    },
  }),
})

This enables tracing, log forwarding, and metrics. Mastra also supports external tracing providers like Langfuse, Datadog, and any OpenTelemetry-compatible platform. See Tracing for configuration details.

Storage
Direct link to Storage

Not all storage backends support every signal. Traces and logs work with most backends, but metrics require an OLAP-capable store like DuckDB (development) or ClickHouse (production). For the full compatibility list, see storage provider support.

For production environments with high traffic, use composite storage to route the observability domain to a dedicated backend. See production recommendations for details.

Next steps
Direct link to Next steps

On this page