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.
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"}
histogram_quantile(0.95,
sum by (upstream, le) (
rate(relaygate_request_duration_seconds_bucket[5m])
))
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.
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
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.