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

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

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.

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.

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