# What is Observability?

Also called telemetry, monitoring.

Observability is the degree to which the internal state of a running system can be understood from the data it emits, mainly logs, metrics, and traces. A system is observable when an operator can answer new questions about a failure without shipping new code to collect more data. It is a property of the system, not a single tool.

Observability is usually built on three kinds of telemetry. Metrics are cheap aggregate numbers such as error rate and request duration, good for detecting that something changed. Logs are discrete records of events with detail. Traces connect the steps of a single request. Systems built on language models add a fourth family: prompts, model configuration, tool calls, token counts, and evaluation scores attached to individual runs.

The value shows up when a failure is not one that anyone anticipated. Agents call external tools, run for minutes, and take different paths for different inputs, so the useful question is often narrow, for example whether the failures share one tenant, one tool, or one document type. Answering that requires data already recorded at sufficient granularity, because the failing run cannot be reproduced on demand.

The most common mistake is equating observability with dashboards. A dashboard answers a question someone already thought of. Two related traps are cardinality, where adding a unique identifier as a metric label makes storage explode, and sampling, which quietly discards the rare runs that matter most. Recording prompts and tool payloads also captures personal data, so redaction and retention limits belong in the design, not added later.

Monitoring and observability are often used interchangeably, and the distinction is contested. The useful reading is that monitoring watches known conditions and fires alerts, while observability is the broader capability to investigate conditions nobody predefined. Tracing and spans are the main mechanism for the second. Neither replaces the other, and an alert without underlying detail leaves a responder knowing that something broke and nothing more.

## Key points

- Built on logs, metrics, and traces, often called the three pillars.
- Measures whether unknown failures can be diagnosed without new instrumentation.
- Agent systems add prompts, tool calls, and token counts as signals.
- Collecting data is useless unless questions can be asked of it.

## In practice

An agent that files expense reports starts failing for some users only. Metrics show error rate rising, so the operator opens a trace for one failed run and sees the accounting tool returning a permission error after a token refresh. Nothing new had to be instrumented, because the tool call, its arguments, and its response were already recorded. The fix takes minutes rather than a day.

## Related terms

- [Tracing](/en/glossary/tracing)
- [Span](/en/glossary/span)
- [Alerting](/en/glossary/alerting)
- [LLMOps](/en/glossary/llmops)
- [Agent trajectory logging](/en/glossary/agent-trajectory-logging)

[Back to the AI Glossary](/en/glossary)