Integrations / OpenTelemetry

Bring any agent framework into the same run model.

Your agent stays in its own repository and deployment. Emit stable OpenTelemetry service identity and Tracey can correlate the run with model, tool, dependency, and infrastructure evidence.

Instrumentation boundary

Tracey does not vendor or execute your agent source code. Your application emits telemetry through the OpenTelemetry SDK or Collector, and Tracey consumes the resulting evidence from SigNoz.

  • Instrument at the agent entry point
  • Propagate trace context across model and tool calls
  • Export through an OpenTelemetry Collector where possible
  • Keep sensitive content out of attributes and event bodies

Minimum run contract

A useful first integration needs a stable root run, an outcome, service identity, and trace correlation. Add child spans as you need deeper diagnosis.

agent.run
  tracey.run.id: stable run identifier
  tracey.agent.id: registered service identity
  tracey.environment: staging | production
  tracey.outcome: success | failure | timeout
  trace_id: propagated across child activity

Recommended child spans

Use semantic span names that preserve the execution path. The exact framework is not important; causal relationships and stable attributes are.

  • agent.route for routing and planning decisions
  • gen_ai.chat for model calls and token usage
  • tool.call or mcp.request for external actions
  • retrieval.query for vector or knowledge lookups
  • agent.handoff for multi-agent transitions
  • agent.result for final outcome classification

Privacy defaults

Do not export prompts, model responses, tool arguments, tool results, credentials, personal data, or raw private application content by default. Prefer IDs, hashes, versions, timings, counts, and outcome classes.

Tracey’s investigations are only as strong as the evidence you choose to emit. Privacy-safe telemetry can still support latency, failure, cost, and dependency analysis.