Monitor Mastra with Sazabi

Last verified on Nov 8, 2026.

Mastra is a TypeScript framework where agents, tools and workflows run inside one process. When an answer is wrong, the question is rarely about one function. It is about which tool the agent chose, what the model saw and how many steps it took.

Mastra records that path as spans. Sazabi, the AI-native observability and security platform, takes them as a manual log source, so the agent run sits next to the application logs from the same service. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run.

What Sazabi reads from Mastra

One method, one direction. Your Mastra app exports OTLP spans to your Sazabi intake URL, and Sazabi never calls back into the app.

The Sazabi docs for this source use Mastra's OtelExporter from @mastra/otel-exporter, inside an Observability config from @mastra/observability. The provider is custom, the endpoint reads SAZABI_INTAKE_URL, and the protocol is http/json. Because Mastra batches the spans, you do not configure the OpenTelemetry SDK yourself.

Mastra's reference for the exporter adds details that shape what arrives. Traces follow the GenAI semantic conventions. The custom config takes either endpoint, where Mastra derives the signal paths from one collector URL, or endpoints, with an exact URL per signal. The default protocol is http/json. Batches hold 512 spans or logs by default and the export timeout is 30000 ms. The exporter can also send logs. The Sazabi page documents the trace setup.

Mastra's tracing overview names the span types. AGENT_RUN is an agent run, TOOL_CALL a tool call, and MODEL_STEP and MODEL_CHUNK the model's steps and streamed chunks. The Sazabi docs list one cause of missing agent spans: an agent that is not registered with your Mastra instance produces none.

Questions it answers

• How many steps did one agent run take, and which tools did it call?
• Which tool call ran longest in a slow request?
• Did a deploy change the number of model steps per run?
• Which agent produced the failing run a customer reported?
• What did the service log while that run was in flight?
• How many spans does streaming add, and is that volume worth keeping?

A worked example: tracing one customer request

Mastra helps with support cases. When you run agent.generate, the response includes a traceId, which Mastra says is meant for debugging, customer support and correlating with other events. Store that id next to the customer's ticket. Later, a ticket says the agent answered with stale prices. You have the trace id from your own logs, say 4bf92f3577b34da6a3ce929d0e0e4736.

Ask the Sazabi agent in a thread:

For service my-mastra-app, show every span in trace 4bf92f3577b34da6a3ce929d0e0e4736
in start order. Which TOOL_CALL spans ran, and what came back from each?

Read the answer in order. The AGENT_RUN span frames the request. Under it, MODEL_STEP spans are the model's turns and TOOL_CALL spans are the tools it chose. If the pricing tool ran and returned old data, the fault is in the tool or its source. If no pricing tool ran, the model answered from its own context, which is a prompt or tool-description problem. These are two different fixes, and you know which one you need after one query.

Keeping volume sensible

Streaming creates many MODEL_CHUNK spans. Mastra's excludeSpanTypes option drops whole span types, for example MODEL_CHUNK and MODEL_STEP, before export. Mastra also supports ratio-based sampling and custom sampling on the observability config. Choose these in Mastra. Sazabi stores what arrives.

How it fits with other integrations

Mastra sits with the other tools under AI frameworks. LangChain reaches Sazabi through OpenInference rather than a built-in exporter, and OpenRouter adds a span per generation from the gateway side. The shared protocol is described on the OpenTelemetry integration page. For how volume is counted, see pricing.