Product FAQ and data reference

Understand Observagent and the data it receives.

Observagent brings AI telemetry together so teams can understand behavior, improve systems, and reduce unnecessary resource use. This page also explains the information an integration may send.

Product FAQ

What, how, and why

What is Observagent?

Observagent is observability infrastructure for AI systems. It brings metrics, traces, logs, and usage data together so organizations can see how AI behaves across users, agents, applications, and departments.

How does Observagent work?

Your SDK, runtime, or local integration emits OpenTelemetry signals over HTTPS. Observagent organizes those signals for investigation and analysis. The resulting telemetry helps teams identify what works, uncover what does not, and improve performance, reliability, and cost.

Why does Observagent exist?

AI systems are difficult to improve responsibly when their behavior and resource use are opaque. Observagent's goal is to make every AI interaction observable, helping teams reduce unnecessary AI activity and resource consumption while building more efficient, sustainable systems.

Backend data

What gets sent to Observagent

Integrations send OpenTelemetry traces, metrics, and logs over HTTPS. The exact fields and content depend on the SDK, runtime, instrumentors, and configuration you choose.

Your integrationChooses fields and content
OTLP over HTTPSOpenTelemetry signals
ObservagentExplore and analyze telemetry
The payload depends on your exporterObservagent does not need prompt or response text to accept telemetry. However, an SDK or automatic instrumentor can place model content, retrieval queries, tool output, URLs, exception messages, or other application data in attributes, span events, or log bodies. Review those settings before enabling an integration in production.
Payload reference

Fields retained for each signal

Backend fields derived from incoming OTLP records
SignalData retained
All signalsReceive time; agent, session, and user identifiers when supplied; resource attributes; and record or datapoint attributes supplied by the exporter.
View example telemetry
Common fields · JSON
{
  "timestamp": "2026-09-27T18:42:11Z",
  "service.name": "support-assistant",
  "agent.id": "triage-agent",
  "session.id": "session-7f3a",
  "user.id": "user-anonymous-42",
  "environment": "production"
}
TracesTrace, span, and parent IDs; span name; start/end time and duration; status code and message; span events and their attributes; and span links.
View example telemetry
Trace · JSON
{
  "trace.id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span.id": "00f067aa0ba902b7",
  "parent.span.id": "b7ad6b7169203331",
  "span.name": "chat.completion",
  "start_time": "2026-09-27T18:42:11.000Z",
  "end_time": "2026-09-27T18:42:11.842Z",
  "duration_ms": 842,
  "status": "OK",
  "attributes": {
    "gen_ai.system": "example-provider",
    "gen_ai.request.model": "example-model"
  }
}
MetricsMetric name, description, unit, type, timestamps, numeric value, histogram or summary values, buckets, bounds, quantiles, and exemplars with trace/span correlation.
View example telemetry
Metric · JSON
{
  "timestamp": "2026-09-27T18:42:11Z",
  "metric.name": "gen_ai.client.token.usage",
  "description": "Number of tokens used",
  "unit": "{token}",
  "type": "histogram",
  "count": 1,
  "sum": 174,
  "attributes": {
    "gen_ai.request.model": "example-model",
    "gen_ai.token.type": "input"
  }
}
LogsEvent and observed timestamps; severity text and number; log body; attributes; and optional trace and span IDs.
View example telemetry
Log · JSON
{
  "timestamp": "2026-09-27T18:42:11Z",
  "observed_timestamp": "2026-09-27T18:42:11.025Z",
  "severity": "INFO",
  "body": "Model request completed",
  "trace.id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span.id": "00f067aa0ba902b7",
  "attributes": {
    "event.name": "gen_ai.client.operation",
    "gen_ai.operation.name": "chat"
  }
}
Privacy checklist

Control what your integration sends

  • Use opaque, non-sensitive values for agent, session, and user IDs.
  • Disable prompt and response capture unless the use case requires it.
  • Do not put secrets, credentials, or access tokens in attributes or log bodies.
  • Review automatic model, HTTP, database, and tool instrumentation before production.
  • Redact or omit sensitive queries, exception text, URLs, headers, and tool output.
  • Enable only the trace, metric, and log signals needed by the project.
Review telemetry data