LLM and Agentic Observability
Answer user questions about monitoring LLMs and agentic components using data ingested into Elastic only. Focus on
LLM performance, cost and token utilization, response quality, and call chaining or agentic workflow orchestration. Use
ES|QL, Elasticsearch APIs, and (where needed) Kibana APIs. Do not rely on Kibana UI; the skill works without it. A
given deployment typically uses one or more ingestion paths (APM/OTLP traces and/or integration metrics/logs)—
discover what is available before querying.
Where to look
- Trace and metrics data (APM / OTel): Trace data in Elastic is stored in
traces* when collected by the
Elastic APM Agent, and in traces-generic.otel-default (and similar) when collected by OpenTelemetry. Use the
generic pattern traces* to find all trace data regardless of source. When the application is instrumented with
OpenTelemetry (e.g. Elastic
Distributions of OpenTelemetry (EDOT),
OpenLLMetry, OpenLIT, Langtrace exporting to OTLP), LLM and agent spans land in these trace data streams; metrics may
land in metrics-apm* or metrics-generic. Query traces* and metrics* data streams for per-request and
aggregated LLM signals.
- Integration metrics and logs: When the user collects data via
Elastic LLM integrations
(OpenAI, Azure OpenAI, Azure AI Foundry, Amazon Bedrock, Bedrock AgentCore, GCP Vertex AI, etc.), metrics and logs go
to integration data streams (e.g.
metrics*, logs* with dataset/namespace per integration). Check which data
streams exist.
- Discover first: Use Elasticsearch to list data streams or indices (e.g.
GET _data_stream, or
GET traces*/_mapping, GET metrics*/_mapping) and optionally sample a document to see which LLM-related fields are
present. Do not assume both APM and integration data exist.
- ES|QL: Use the elasticsearch-esql skill for ES|QL syntax, commands, and query patterns when building queries
against
traces* or metrics data streams.
- Alerts and SLOs: Use the Observability APIs SLOs
API (Stack |
Serverless) and Alerting API
(Stack |
Serverless) to find SLOs and alerting rules
that target LLM-related data (e.g. services backed by
traces*, or integration metrics). Firing alerts or
violated/degrading SLOs point to potential degraded performance.
Data available in Elastic
From traces and metrics (traces*, metrics-apm* / metrics-generic)
Spans from OTel/EDOT (and compatible SDKs) carry span attributes that may follow
OpenTelemetry GenAI semantic conventions or
provider-specific names. In Elasticsearch, attributes typically appear under span.attributes (exact key names depend
on ingestion). Common attributes:
| Purpose |
Example attribute names (OTel GenAI) |
| Operation / provider |
gen_ai.operation.name, gen_ai.provider.name |
| Model |
gen_ai.request.model, gen_ai.response.model |
| Token usage |
gen_ai.usage.input_tokens, gen_ai.usage.output_tokens |
| Request config |
gen_ai.request.temperature, gen_ai.request.max_tokens |
| Errors |
error.type |
| Conversation / agent |
gen_ai.conversation.id; tool/agent spans as child spans |
Cost is not in the OTel spec; some instrumentations add custom attributes (e.g. llm.response.cost.usd_estimate).
Discover actual field names from the index mapping or a sample document (e.g. span.attributes.* or flattened keys).
Use duration and event.outcome on spans for latency and success/failure. Use trace.id, span.id, and
parent/child span relationships to analyze call chaining and agentic workflows (e.g. one root span, multiple LLM or
tool-call child spans).
From LLM integrations
Integrations (OpenAI, Azure OpenAI, Azure AI Foundry, Bedrock, Bedrock AgentCore, Vertex AI, etc.) ship metrics (and
where supported logs) to Elastic. Metrics typically include token usage, request counts, latency, and—where the
integration supports it—cost-related fields. Logs may include prompt/response or guardrail events. Exact field names and
data streams are defined by each integration package; discover them from the integration docs or from the target data
stream mapping.
Determine what data is available
- List data streams:
GET _data_stream and filter for traces*, metrics-apm* (or metrics*), and metrics-* /
logs-* that match known LLM integration datasets (e.g. from
Elastic LLM observability).
- Inspect trace indices: For
traces*, run a small search or use mapping to see if spans contain gen_ai.* or
llm.* (or similar) attributes. Confirm presence of token, model, and duration fields.
- Inspect integration indices: For metrics/logs data streams, check mapping or one document to see token, cost,
latency, and model dimensions.
- Use one source per use case: If both APM and integration data exist, prefer one consistent source for a given
question (e.g. use traces for per-request chain analysis, integration metrics for aggregate token/cost).
- Check alerts and SLOs: Use the SLOs API and Alerting API to list SLOs and alerting rules that target LLM-related
services or integration metrics, and to get open or recently fired alerts. Firing alerts or SLOs in
degrading/violated status point to potential degraded performance.
Use cases and query patterns
LLM performance (latency, throughput, errors)
- Traces: ES|QL on
traces* filtered by span attributes (e.g. gen_ai.operation.name or gen_ai.provider.name
when present). Compute throughput (count per time bucket), latency (e.g. duration.us or span duration), and error
rate (event.outcome == "failure") by model, service, or time.
- Integrations: Query integration metrics for request rate, latency, and error metrics by model/dimension as exposed
by the integration.
Cost and token utilization
- Traces: Aggregate from spans in
traces*: sum gen_ai.usage.input_tokens and gen_ai.usage.output_tokens (or
equivalent attribute names) by time, model, or service. If a cost attribute exists (e.g. custom
llm.response.cost.*), sum it for cost views.
- Integrations: Use integration metrics that expose token counts and/or cost; aggregate by time and model.
Response quality and safety
- Traces: Use
event.outcome, error.type, and span attributes (e.g. gen_ai.response.finish_reasons) in
traces* to identify failures, timeouts, or content filters. Correlate with prompts/responses if captured in
attributes (e.g. gen_ai.input.messages, gen_ai.output.messages) and not redacted.
- Integrations: Query integration logs for guardrail blocks, content filter events, or policy violations (e.g.
Bedrock Guardrails)
using the fields defined by that integration.
Call chaining and agentic workflow orchestration
- Traces only: Use trace hierarchy in
traces*. Filter by root service or trace attributes; group by trace.id
and use parent/child span relationships (e.g. parent.id, span.id) to reconstruct chains (e.g. orchestration span →
multiple LLM or tool-call spans). Aggregate by span name or gen_ai.operation.name to see distribution of steps (e.g.
retrieval, LLM, tool use). Duration per span and per trace gives bottleneck and end-to-end latency.
Using ES|QL for LLM data
- Availability: ES|QL is available in Elasticsearch 8.11+ (GA in 8.14) and in Elastic Observability Serverless.
- Scoping: Always restrict by time range (
@timestamp). When present, add service.name and optionally
service.environment. For LLM-specific spans, filter by span attributes once you know the field names (e.g. a keyword
field for gen_ai.provider.name or gen_ai.operation.name).
- Performance: Use
LIMIT, coarse time buckets when only trends are needed, and avoid full scans over large
windows.
Workflow
LLM observability progress:
- [ ] Step 1: Determine available data (traces*, metrics-apm* or metrics*, or integration data streams)
- [ ] Step 2: Discover LLM-related field names (mapping or sample doc)
- [ ] Step 3: Run ES|QL or Elasticsearch queries for the user's question (performance, cost, quality, orchestration)
- [ ] Step 4: Check for active alerts or SLOs defined on LLM-related data (Alerting API, SLOs API); field names from
Step 2 help identify related rules; firing alerts or violated/degrading SLOs indicate potential degraded performance
- [ ] Step 5: Summarize findings from ingested data only; include alert/SLO status when relevant
Examples
Example: Token usage over time from traces
Assume span attributes are available as span.attributes.gen_ai.usage.input_tokens and
span.attributes.gen_ai.usage.output_tokens (adjust to actual field names from mapping):
FROM traces*
| WHERE @timestamp >= "2025-03-01T00:00:00Z" AND @timestamp <= "2025-03-01T23:59:59Z"
AND span.attributes.gen_ai.provider.name IS NOT NULL
| STATS
input_tokens = SUM(span.attributes.gen_ai.usage.input_tokens),
output_tokens = SUM(span.attributes.gen_ai.usage.output_tokens)
BY BUCKET(@timestamp, 1 hour), span.attributes.gen_ai.request.model
| SORT @timestamp
| LIMIT 500
Example: Latency and error rate by model
FROM traces*
| WHERE @timestamp >= "2025-03-01T00:00:00Z" AND @timestamp <= "2025-03-01T23:59:59Z"
AND span.attributes.gen_ai.request.model IS NOT NULL
| STATS
request_count = COUNT(*),
failures = COUNT(*) WHERE event.outcome == "failure",
avg_duration_us = AVG(span.duration.us)
BY span.attributes.gen_ai.request.model
| EVAL error_rate = failures / request_count
| LIMIT 100
Example: Agentic workflow (trace-level view)
Get trace IDs that contain at least one LLM span and count spans per trace to see chain length:
FROM traces*
| WHERE @timestamp >= "2025-03-01T00:00:00Z" AND @timestamp <= "2025-03-01T23:59:59Z"
AND span.attributes.gen_ai.operation.name IS NOT NULL
| STATS span_count = COUNT(*), total_duration_us = SUM(span.duration.us) BY trace.id
| WHERE span_count > 1
| SORT total_duration_us DESC
| LIMIT 50
Example: Integration metrics (Amazon Bedrock AgentCore)
The Amazon Bedrock AgentCore integration
ships metrics to the metrics-aws_bedrock_agentcore.metrics-* data stream (time series index). Use TS for
aggregations on time series data streams (Elasticsearch 9.2+); use a time range with TRANGE (9.3+). The
integration’s dashboards and
alerting rule templates
Example: token usage (counter), invocations (counter), and average latency (gauge) by hour and agent:
TS metrics-aws_bedrock_agentcore.metrics-*
| WHERE TRANGE(7 days)
AND aws.dimensions.Operation == "InvokeAgentRuntime"
| STATS
total_tokens = SUM(RATE(aws.bedrock_agentcore.metrics.TokenCount.sum)),
total_invocations = SUM(RATE(aws.bedrock_agentcore.metrics.Invocations.sum)),
avg_latency_ms = AVG(AVG_OVER_TIME(aws.bedrock_agentcore.metrics.Latency.avg))
BY TBUCKET(1 hour), aws.bedrock_agentcore.agent_name
| SORT TBUCKET(1 hour) DESC
For Elasticsearch 8.x or when TS is not available, use FROM with BUCKET(@timestamp, 1 hour) and SUM/AVG over
the metric fields (as in the integration's alert rule templates). For other LLM integrations (OpenAI, Azure OpenAI,
Vertex AI, etc.), use that integration’s data stream index pattern and field names from its package (see
Elastic LLM observability).
Guidelines
- Data only in Elastic: Use only data collected and stored in Elastic (traces in
traces*, metrics, or integration
metrics/logs). Do not describe or rely on other vendors’ UIs or products.
- One technology per customer: Assume a single ingestion path per deployment when answering; discover which (traces
vs integration) exists and use it consistently for the question.
- Discover field names: Before writing ES|QL or Query DSL, confirm LLM-related attribute or metric names from
_mapping or a sample document; naming may differ (e.g. gen_ai.* vs llm.* or integration-specific fields).
- No Kibana UI dependency: Prefer ES|QL and Elasticsearch APIs; use Kibana APIs only when needed (e.g. SLO,
alerting). Do not instruct the user to open Kibana UI.
- References:
LLM and agentic AI observability,
Observability Labs – LLM Observability,
OpenTelemetry GenAI spans. For ES|QL syntax and
query patterns, use the elasticsearch-esql skill, or look through
ES|QL TS command reference for Elastic v9.3
or higher and for Serverless, and look through
ES|QL FROM command reference for other
Elastic versions.
