Docs · Observability

Metrics, traces, signed receipts.

RelayGate emits three observability artifacts per request: a Prometheus metric update, an OpenTelemetry trace span, and an Ed25519-signed receipt. All three speak the shapes your existing tools already understand.

Prometheus metrics

Every instance exposes /metrics in the Prometheus text format. Scrape it from any Prometheus-compatible collector.

# top-line counters + histograms
relaygate_requests_total{upstream="openai",outcome="ok"}
relaygate_request_duration_seconds_bucket{upstream="openai",le="0.005"}
relaygate_request_duration_seconds_sum
relaygate_request_duration_seconds_count

# worker overhead
relaygate_worker_duration_seconds_bucket{worker="pii-scrub",stage="pre-request",le="0.0005"}

# circuit-breaker state
relaygate_circuit_state{upstream="openai"}    # 0=closed 1=half 2=open

# policy outcomes
relaygate_policy_eval_total{policy="route-by-plan",outcome="allow"}

Example query: P95 by upstream

histogram_quantile(0.95,
  sum by (upstream, le) (
    rate(relaygate_request_duration_seconds_bucket[5m])
  ))

OpenTelemetry traces

Traces export over OTLP (gRPC or HTTP). Every request produces a root span relaygate.request with child spans per worker and one for the upstream call.

# config.yaml
observability:
  otlp:
    endpoint: "http://otel-collector.internal:4317"
    protocol: grpc
    resource:
      service.name: relaygate
      deployment.environment: prod

Span attributes include the tenant id, route id, upstream id, worker id, and the receipt id. Use the receipt id to correlate a trace with its receipt.

Signed receipts

Every request produces one Ed25519-signed receipt. Signatures are verifiable offline with the public key published at /.well-known/relaygate-receipt-key.

{
  "id": "rcpt_01HY7K...",
  "ts": "2026-04-23T14:22:18.182Z",
  "tenant": "tenant_acme",
  "route": "openai",
  "upstream": "openai",
  "model": "gpt-4o-mini",
  "tokens_in": 42,
  "tokens_out": 17,
  "cost_usd": 0.00011,
  "overhead_us": 238,
  "workers": [
    { "id": "pii-scrub", "stage": "pre-request", "dur_us": 46, "redactions": 1 },
    { "id": "metering",  "stage": "post-response", "dur_us": 28 }
  ],
  "annotations": { "intent": "support-question" },
  "signature": "ed25519:Y4s...XFw="
}

Verify a batch offline:

relaygate receipt verify receipts-2026-04-23.ndjson --key /etc/relaygate/keys/relaygate.pub

Integrations

  • Grafana: pre-built dashboard JSON at observability/grafana. Import and point at your Prometheus source.
  • Datadog: the OpenMetrics integration scrapes the Prometheus endpoint directly; traces land via the Datadog OTLP collector.
  • Honeycomb: point OTLP at Honeycomb's ingest; the service name propagates automatically.
  • Managed console: Managed tier includes a hosted console with receipt search, per-tenant rollups, and drift alerts.

Why signed receipts

Logs can be tampered with. Traces can be dropped. A signed receipt is a verifiable proof that a specific request was handled by a specific gateway instance with a specific policy. The receipt format is TrueCom-compatible, which matters the moment agents start settling work against each other.

Back to docs index.