Your telemetry, your control

Keep your agent traffic’s logs, metrics, and traces in your own stack and compliance boundary, not locked in a vendor console.

When agents act on their own across production systems, you need their telemetry in the tools your team already runs, for incident response, capacity planning, and audit. Many platforms trap that data in their own console or limit where it can be sent, and that becomes a real constraint when your logs must stay inside a specific compliance boundary.

What you can do

  • Export traces, metrics, and logs to your own OpenTelemetry (OTLP) collector so that the data lands in tools you already run, such as Jaeger, Tempo, or Datadog.
  • Scrape metrics with Prometheus and stream logs and metrics to AWS CloudWatch so that each environment reports into its native stack.
  • Send to several backends at once so that live dashboards, long-term storage, and cloud-native monitoring all receive the same data.
  • Correlate a request across every signal with one trace id so that its metrics, spans, and audit records tie together, even across gateway hops.
  • Mask sensitive fields with redaction rules so that credentials never leave your boundary in a log or a span.

How it works

Requestthrough the gatewaytrafficAgent GatewayEmits three signals per requestMetricsTrace spanLogsCorrelated by one X-Gateway-Trace-IdRedaction applied to every destinationBackend down? Export backs off; requests unaffectedDESTINATIONS · ANY SUBSET, AT ONCEIn-dashboard live viewlive logs, charts, state (built in)Prometheusscrape metricsAWS CloudWatchlogs and metricsOTLP collectorJaeger, Tempo, Datadog

Every request produces three signals: a metrics record, a distributed trace span, and structured logs. A background worker fans these out to whichever backends you configure, so metrics can persist to a local store, Prometheus, AWS CloudWatch, and an OTLP collector at the same time. Traces propagate with W3C traceparent, and each request carries an X-Gateway-Trace-Id that also appears on its metrics, its audit entries, and the injected workload-binding presentation, giving one identifier from the caller through to the downstream service.

Each metrics record includes the surface id, source and destination, status (success, failed, or gateway fault), request and response byte counts, retry count, latency, and an agent identity hash for attribution. A configurable redaction ruleset is applied to every destination, including exported OpenTelemetry span attributes; the default ruleset already masks Authorization and Proxy-Authorization credentials such as Bearer, Basic, and API-key values.

If an external backend is unreachable, its exporter backs off and drops that batch rather than blocking, so request forwarding and the in-dashboard live view carry on unaffected.

  • Observability: How the gateway produces metrics, traces, and logs and which backends each can reach.
  • Metrics: Reference for every field emitted on a request record.
  • Dashboard: The in-dashboard live plane for real-time diagnosis.
  • Audit log: Tamper-evident policy and trust records correlated by trace id.