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/logsCurrent 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
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.
Reliability mechanics
Throughput and benchmarking
We are not publishing a Gateway events-per-second number until the benchmark is reproducible across payload size, policy complexity, replica count, CPU/memory, and downstream behavior. The published benchmark will report events/sec and MB/sec together with p50/p95/p99 added latency, CPU, memory, and test conditions.
CerbiStream already has reproducible BenchmarkDotNet results. Those numbers are not Gateway numbers and are kept separate intentionally.
See CerbiStream benchmarksRecommended 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