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
Controlled preview / Marketplace release candidate
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
Why the throughput number is not on the cover
A useful benchmark needs context.
Events/sec changes with payload size, policy complexity, batching, CPU/memory, replica count, and downstream behavior. Cerbi will publish Gateway throughput with MB/sec, p50/p95/p99 added latency, CPU, memory, payload shape, policy cost, replica count, and destination conditions. Until then, claiming a large naked number would be marketing, not engineering evidence.
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