Where Gateway fits

Gateway sits between OTLP producers and a downstream OTLP destination. It does not replace your application logger, OpenTelemetry instrumentation, Collector strategy, or observability platform.

Existing producers

Applications, agents, auto-instrumentation, and Collectors keep emitting OTLP.

Cerbi Gateway

Validate, verify signed policy, govern, retain bounded evidence, and forward.

Existing destination

Your downstream observability and routing stack remains in place.

Adoption model

No Cerbi SDK is required when a workload already emits OTLP. Route that workload, agent, or existing Collector through the Gateway endpoint. Workloads that do not emit OTLP still need normal OpenTelemetry instrumentation or an agent/Collector.

# Conceptual example
OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://<gateway-host>/v1/logs

Optional AI log observations

When AI Logging Governance is enabled in CerbiShield Pro++, Gateway can normalize selected OTLP log records that carry OpenTelemetry GenAI-style attributes into metadata-only AI logging observations. This is an explicit runtime path: customers choose the workloads or collectors that route through Gateway.

Provider, model, operation, agent, tool, app, and environment metadata where present

Input/output/total token counts and cost hints where emitted as numeric metadata

Raw prompt, completion, RAG context, and tool-argument values omitted from the observation payload

Observation export failures recorded as processor metrics without breaking the OTLP forwarding path

This current bridge is for OTLP log records. Trace, metric, and deeper agent-action correlation belong to the broader AI governance roadmap and should be introduced only as those explicit integrations mature.

Current technical contract

Ingestion

HTTPS OTLP/HTTP at /v1/logs

Request boundary

20 MiB maximum OTLP/HTTP body

Source access

Customer-approved CIDR

Downstream

OTLP/gRPC over TLS

AI observation export

Opt-in, metadata-only, logs-first

Policy refresh

30-second signed-bundle refresh

Baseline

0.5 vCPU / 1 GiB before horizontal scale

Policy and security

CerbiShield publishes signed Runtime Policy Bundles inside the customer environment. Gateway requires cryptographic verification before using the active bundle. The Marketplace design uses a customer-local, non-exportable P-256 signing key in Azure Key Vault and a non-public customer-local storage container for runtime policy.

HTTPS-only public ingestion

Customer-restricted source CIDR

Required signed-policy verification

Customer-local signing and policy storage

TLS downstream transport

No Cerbi-hosted raw-log relay

Reliability mechanics

Bounded memory limiting before batch processing

Queued downstream export with multiple consumers

Bounded retry behavior for temporary downstream failure

Dedicated liveness and readiness probes

Minimum one running replica with plan-controlled horizontal scaling

Local runtime-policy cache for continuity between refreshes

Throughput and benchmarking

A live v1.10.80 baseline measured 19.1K–19.5K events/sec with 50-event, 13.6-KiB OTLP requests on one 0.5-vCPU / 1-GiB replica. Across three runs, every request returned HTTP 200 with zero client errors; p95 request latency was 194–197 ms. The test used observe mode and the dormant debug exporter with no downstream destination, so the result is a bounded baseline rather than a plan capacity limit or forwarding-path SLA.

CerbiStream already has reproducible BenchmarkDotNet results. Those numbers are not Gateway numbers and are kept separate intentionally.

See performance evidence

Recommended evaluation

01Choose one non-production workload that already emits OTLP logs.
02Deploy CerbiShield into the customer Azure tenant.
03Configure the downstream OTLP destination and an explicit source CIDR.
04Route the selected workload through Gateway.
05Publish a signed governance policy to that workload target.
06Review behavior, evidence, health, and measured overhead before wider rollout.

Evaluate it against real OTLP traffic.

The useful proof is routing, signed-policy activation, governance behavior, evidence, and operational overhead against traffic that resembles your environment.

Request an evaluation