Cerbi Gateway: governed OpenTelemetry without replacing the observability stack
Cerbi Gateway is a customer-hosted enforcement point for organizations that already move telemetry through OpenTelemetry. It gives platform and security teams a central policy boundary while leaving application loggers, standard OTel instrumentation, and downstream observability platforms in place.
Deployment
Customer-hosted Azure Container App
Protocol
OpenTelemetry logs via HTTPS OTLP/HTTP
Policy
Signed, versioned Runtime Policy Bundle
Destination
Customer-configured downstream OTLP/gRPC
Identity
Customer workload targeting + CerbiShield policy assignment
Status
Available with CerbiShield v1.10.80
The problem Gateway is designed to solve
Most observability stacks are very good at storing, searching, correlating, alerting on, and visualizing telemetry. That does not automatically give an organization one governed answer to a different question: what is allowed to be emitted, under which policy, for which workload, and how can we prove the rule was actually active?
Teams can build individual Collector processors and pipeline rules, but those controls are usually configuration artifacts rather than a complete policy lifecycle. Cerbi adds central authoring, workload targeting, signed policy distribution, enforcement choices, validation, deployment history, exceptions, and evidence.
Architecture
OTLP producers
Apps, agents, auto-instrumentation, Collectors
Cerbi Gateway
Validate, verify policy, govern, evidence, forward
Existing backend
Downstream OTLP and observability destinations
CerbiShield operates above this path as the control and evidence plane. It manages governance profiles, targets, deployments, validation, violations, reporting, audit context, and platform health.
Security model
Gateway executes inside the customer Azure environment.
Public ingestion is HTTPS-only and limited to a customer-approved source CIDR.
Runtime policy requires cryptographic signature verification before activation.
The Marketplace design uses a customer-local, non-exportable P-256 Key Vault signing key.
Runtime policy is stored in a non-public customer-local Blob container.
Downstream OTLP transport uses TLS; Cerbi does not operate a hosted raw-log relay for Gateway traffic.
Reliability and performance mechanics
Gateway is configured as a production telemetry path rather than a synchronous call to a remote policy service. The current contract includes bounded memory, batch processing, queued downstream export, bounded retry behavior, liveness/readiness probes, at least one running replica, and horizontal scaling controlled by the selected plan.
HTTP guardrail
20 MiB max request body
Memory limiter
512 MiB + 128 MiB spike
Policy refresh
30 seconds
Export queue
2,048 items / 4 consumers
Retry
5s → 30s, max 300s elapsed
Baseline
0.5 vCPU / 1 GiB
Measured v1.10.80 performance baseline
19.1K–19.5K governed events/sec—with the conditions attached.
The live Azure test used 50-event, 13.6-KiB OTLP/HTTP requests over internal HTTPS, 32 client workers, one 0.5-vCPU / 1-GiB Gateway replica, a signed observe-mode policy, and the dormant debug exporter. Across three 20-second runs, every request returned HTTP 200 with zero client errors. p95 request latency was 194–197 ms and p99 was 285–291 ms. Peak working set was about 79 MiB; CPU reached the half-core ceiling. Normalized, the result is approximately 38K events/sec or 10.2 MiB/sec per vCPU, but no multi-replica linear-scaling or downstream-forwarding claim was tested.
Single-event requests
836–907 events/sec · p95 1.31–1.48 ms
10-event batches
11.5K–12.0K events/sec · p95 59.6–64.8 ms
50-event batches
19.1K–19.5K events/sec · p95 194–197 ms
This is an engineering baseline, not a plan capacity limit or forwarding-path SLA. A customer’s payload size, policy complexity, batching, downstream latency, replica count, and debug/production exporter configuration will change the result. Representative pilot testing remains the right sizing method.
Adoption paths
Gateway
Central OTLP boundary
CerbiStream
Inside selected applications
The two paths are complementary. A company can use Gateway for broad OTLP coverage and CerbiStream where the risk model warrants earlier enforcement.
Evaluation criteria
A serious Gateway pilot should prove more than “the page loaded.” Use one non-production OTLP workload and verify routing, request-boundary behavior, signed-policy activation, target resolution, governance outcomes, evidence, downstream continuity, health, and measured overhead using the customer’s representative payload shape.
Put a real workload through it.
A bounded technical evaluation will tell you more than another observability slide deck.
Request an evaluation