Native OpenTelemetry for AI Governance: What We Shipped

AI governance infrastructure needs to be observable. If you cannot see what is happening inside your gateway — which policies are firing, which models are slow, which DLP detections are blocking requests — you cannot operate it with confidence.

This release ships Arbitex’s OpenTelemetry integration: a native OTel SDK, W3C traceparent propagation, OTLP gRPC export, six purpose-built Grafana dashboards, and eight Prometheus alert rules. This post describes what shipped and what it means for teams operating Arbitex in production environments.

What “Native OTel SDK” Actually Means

There is a meaningful difference between a product that exports metrics in an OpenTelemetry format and one that integrates the OpenTelemetry SDK directly.

Arbitex integrates the OTel SDK — not a custom metrics wrapper that translates to OTel at the edge. Instrumentation is authored using OTel API primitives: tracers, spans, meters, log records. This distinction matters to platform engineers who maintain observability infrastructure. SDK-native instrumentation is standards-compliant at the API level, which means trace context propagation and metric semantics work the way your OTel Collector expects them to.

For the teams operating Arbitex: this is the instrumentation layer you would have had to build yourself if we had not shipped it.

W3C Traceparent and Distributed Trace Visibility

Every AI governance request passing through Arbitex carries W3C traceparent context.

When a request arrives at the Arbitex Outpost carrying a traceparent header from your calling application, Arbitex creates a child span linked to that incoming trace context. The trace continues through policy evaluation, DLP inspection, and the upstream provider call — all within the same distributed trace your platform engineers are already watching.

For teams using distributed tracing in production: an AI call that goes through Arbitex is now visible in the same trace tree as the rest of your application. You can see the full latency breakdown — how long Arbitex spent on DLP, how long the provider call took, whether policy evaluation was the bottleneck — without context switching to a separate AI-specific monitoring tool.

If a request arrives without a traceparent header, Arbitex initiates a new trace context. Either way, every request is traced.

Auto-Instrumentation: FastAPI, httpx, SQLAlchemy

Three components of the Arbitex Outpost are auto-instrumented via the OTel SDK:

• FastAPI — the inbound request handling layer
• httpx — outbound calls to upstream AI providers
• SQLAlchemy — policy store and audit log database operations

Auto-instrumentation means spans are emitted by the SDK based on framework hooks — no manual instrumentation of Arbitex internals is required, and no configuration is needed to enable it. The result is a span hierarchy that reflects the actual request lifecycle: an inbound FastAPI span contains child spans for the provider call and any database queries made during policy evaluation.

For SRE teams evaluating where latency is coming from: the trace shows you the answer without requiring custom profiling.

Six Dashboards That Map to Six Operational Surfaces

Six Grafana dashboards ship with this release. Each dashboard is scoped to a distinct surface of the AI governance gateway — not a generic “metrics overview” with a collection of counters.

The six dashboards:

• System health — Outpost process health, request throughput, error rates, and latency percentiles.
• DLP analysis — Detection event rates by tier and type, block and redact action counts, and policy enforcement distribution.
• Provider performance — Upstream provider latency, error rates, and fallback chain activation by provider.
• Usage and billing — Token consumption, request volume, and cost attribution by policy scope.
• Security events — DLP detections, auth failures, policy violations, and audit events in a security-operations view.
• Compliance — Policy coverage, enforcement rate, and audit log integrity metrics for compliance reporting.

Eight Prometheus alert rules cover the thresholds that SRE and SOC teams need to act on: error rate spikes, provider latency degradation, DLP detection anomalies, and Outpost health signals. These are shipped alert definitions — not a list of suggested PromQL expressions. They evaluate against the metrics Arbitex emits via the OTel SDK and are actionable from the first deployment.

Your Existing Observability Stack Works On Day One

Telemetry exports via OTLP gRPC to any compatible collector. The configuration is a single endpoint:

OTEL_EXPORTER_OTLP_ENDPOINT=grpc://your-collector:4317

If your organization runs Grafana Agent, route OTLP there. If you run the OpenTelemetry Collector, point to its gRPC receiver. Datadog, Honeycomb, and self-hosted backends that support OTLP gRPC ingest all work without additional integration work.

Arbitex does not require a specific observability vendor. W3C traceparent and OTLP gRPC are open standards — your decision about where telemetry lives stays in your collector pipeline configuration, not in Arbitex.

The six Grafana dashboards are provided for organizations running Grafana. They are not a requirement. If your organization operates a different dashboard layer, the underlying metrics are available to whatever backend your Prometheus scrape config or OTLP exporter is pointed at.

A Health Endpoint That Integrates with Your Infrastructure

This release also ships a structured health protocol endpoint for liveness and readiness checks. It integrates with Kubernetes probes and load balancer health checks without custom probe configuration. For teams running Arbitex Outpost in Kubernetes: the health endpoint works with standard livenessProbe and readinessProbe configurations out of the box.

What This Changes for Teams Operating Arbitex in Production

Before the latest Arbitex release, observability for the Arbitex Outpost required custom integration work: defining your own metrics, writing your own dashboards, and setting your own alert thresholds.

With the latest Arbitex release, the instrumentation is shipped. Distributed traces connect your application code to Arbitex internals to upstream provider calls in a single trace. The six dashboards give your SRE and SOC teams operational coverage from the first deployment. The eight alert rules define the thresholds that matter for a production AI governance gateway.

For teams evaluating Arbitex for production deployment: observability is not a project you schedule after the initial deployment. It ships with the platform.

The full observability architecture documentation is available at /features/compliance. For questions about integrating Arbitex telemetry with your observability stack, book a technical demo.