AI agents generate significantly more telemetry than traditional services—reasoning traces, token logs, confidence scores, tool invocations—and per-GB pricing from proprietary observability vendors makes this unaffordable at scale, pushing teams to sample aggressively and lose visibility exactly when they need it most. The OpenSearch Observability Stack is presented as an open-source alternative that unifies logs, traces, metrics (via native Prometheus/PromQL integration), agent telemetry, and vector embeddings in a single engine, using PPL or SQL for querying, OpenTelemetry GenAI semantic conventions for agent traces, and Apache 2.0 licensing to avoid vendor lock-in and per-GB ingestion fees. It also covers agent-specific observability signals (reasoning traces, token economics, confidence scoring, decision quality correlation), MCP apps for investigating from Claude Desktop and VS Code, and compliance/data sovereignty benefits for regulated industries.
Table of contents
The fragmentation taxThe per-GB data tax does not scale for agentic workloadsWhat you cannot see is costing you more than what you payWhat an open-source search foundation changesObserving the agentsSovereignty and compliance are not optionalThe path forwardHow to get started with OpenSearch observabilityTake control of your observability costs todayQuestions this post answers
Why does AI agent telemetry cost so much more to store than traditional API observability data?
AI agents generate far more telemetry per request than a REST endpoint because each interaction produces reasoning traces documenting every logic step, token consumption logs across multiple model calls, confidence scores per decision, tool invocation records, and RAG lookup data. A traditional service by comparison only generates a trace span, a few log lines, and metric increments, so per-GB pricing punishes agent-heavy workloads disproportionately. Anyone budgeting for agent observability costs can follow ongoing coverage of this trade-off on daily.dev.
How does OpenSearch handle metrics versus logs and traces for observability?
OpenSearch queries Amazon Managed Prometheus using native PromQL for time-series metrics while storing logs, traces, and agent telemetry directly as first-class data, correlating both signal types in one interface without duplicating data between systems. Logs and traces are queryable via Piped Processing Language (PPL) or SQL, letting each backend handle the signal type it is optimized for. Teams comparing observability architectures can track deep dives like this on daily.dev.
What is the OpenSearch MCP app for agent observability in IDEs like VS Code and Claude Desktop?
It is an open-source Model Context Protocol integration that lets developers run observability investigations directly from Claude Desktop, VS Code, and compatible agentic IDEs, returning a text summary plus interactive visualizations in the conversation thread. This covers log search, metrics correlation, trace exploration, service maps, and topology views without switching consoles. Developers wiring AI tools into their observability workflow can follow tooling updates like this on daily.dev.