Govern before the backend
Apply policy to explicitly routed OTLP logs before forwarding to the configured destination. Trace and metric governance are outside this boundary.
Cerbi Gateway · customer-hosted OTLP logs boundary
Govern OTLP logs
before the backend.
Route existing OTLP log workloads through a customer-hosted enforcement boundary, verify signed policy, retain bounded governance evidence, and keep the observability stack you already operate.
Available with CerbiShield
No Cerbi SDK for existing OTLP log workloadsRuns in the customer Azure environmentExisting destinations stay in place
What Gateway does
A governance boundary, not a filter script.
Gateway handles the enforcement point. CerbiShield handles the policy lifecycle around it.
Adopt without a Cerbi SDK
Workloads that already emit OTLP logs can usually be adopted by changing an endpoint or Collector route rather than modifying application logging code.
Verify signed runtime policy
Gateway requires signed Runtime Policy Bundles so policy authenticity is part of the runtime contract rather than an operational convention.
Keep the observability stack
Forward governed logs to the downstream OTLP destination while preserving the analytics, alerting, retention, and incident workflows already in place.
Retain governance evidence
CerbiShield records bounded policy, deployment, decision, exception, and operational evidence without becoming the raw telemetry destination.
Operate through failure
Runtime policy is cached locally, downstream export is queued and retried, and health probes make Gateway observable as a production service.
Security boundary
Keep policy integrity and telemetry inside the customer boundary.
The deployment model makes ingress, signing, policy storage, and downstream transport explicit rather than hiding them behind a generic “secure by default” claim.
Customer-hostedGateway runs inside the customer Azure environment.
Restricted ingressOTLP ingress is limited to customer-approved network boundaries.
HTTPS onlyMarketplace ingress disallows insecure HTTP and downstream OTLP uses TLS.
Signed policyRuntime bundles require cryptographic signature verification before use.
Customer-local keysSigning keys remain in customer-controlled Azure Key Vault.
Private policy storageRuntime bundles remain in non-public customer-local storage.
Runtime contract
Measured mechanics, with the conditions attached.
Gateway uses the mechanics expected on an OTLP data path: strict request boundaries, cached policy, queued export, retries, health probes, and horizontal scaling. The baseline below was measured against the shipped v1.10.80 Azure deployment.
See performance evidenceOTLP/HTTP
Customer ingress: HTTPS /v1/logs on port 443; internal backend target: 4318
Request boundary
Strict OTLP request validation before processing
Policy refresh
Signed runtime policy is refreshed and cached locally
Downstream delivery
Queued export with bounded retry behavior
Health
Dedicated liveness and readiness probes
Scale
Plan-controlled horizontal scaling and replica replacement
Live v1.10.80 baseline: 19.1K–19.5K events/sec
Three 20-second runs, 50 events per 13.6-KiB request, 32 client workers, internal HTTPS, one 0.5-vCPU / 1-GiB replica, signed observe-mode policy, dormant debug exporter. That normalizes to roughly 38K events/sec or 10.2 MiB/sec per vCPU. All requests returned HTTP 200 with zero client errors; p95 request latency was 194–197 ms. Peak working set was about 79 MiB and CPU reached the half-core ceiling. No downstream destination was active, and the normalized figures are not a linear-scaling claim.
CerbiStream + Gateway
Same governance program. Different enforcement boundary.
Use CerbiStream when control should execute inside selected applications. Use Gateway when existing OTLP log workloads need a shared boundary with less application integration. Mixed estates can use both.
In-process
CerbiStream
Closest to the log call
Policy executes inside the application before the first telemetry network hop. Best for selected workloads where application-level control is worth the integration.
Explore CerbiStreamOTLP logs boundary
Cerbi Gateway
Lower-friction estate adoption
Policy executes on the OpenTelemetry path inside the customer environment. Best when workloads already emit OTLP logs and should not each take a Cerbi SDK dependency.
Read Gateway architectureWhy Cerbi instead of processor config?
The differentiator is everything around enforcement.
OpenTelemetry processors already offer useful transformation and filtering. Evaluate your existing controls first. Cerbi is relevant when an application-focused policy, rollout, or evidence gap remains across selected application and OTLP log paths.
DimensionProcessor configCerbi
Policy lifecycleLocal processor configurationCentral policy authoring, signing, targeting, publishing, and evidence
Change controlRepository or Collector specificVersioned Runtime Policy Bundles with deployment history
Policy authenticityDepends on implementationRequired cryptographic signature verification
EvidenceEvaluate available records and integrationsBounded governance and operational evidence in CerbiShield
Enforcement choicesCollector pathGateway, CerbiStream, or both
Backend strategyDepends on configured exportersObservability-backend agnostic
Questions architects ask
Gateway, without the hand-waving.
Does Gateway require a Cerbi SDK in the application?
No. A workload that already emits OTLP logs can usually be routed through Gateway without adding a Cerbi application package. If it emits no OTLP today, it still needs standard OpenTelemetry instrumentation, an agent, a platform integration, or a Collector.
Does Gateway replace OpenTelemetry Collector?
No. Gateway is built for the OpenTelemetry data path and can sit alongside or behind existing Collectors. Cerbi adds the governance system around policy distribution, verification, enforcement, exceptions, and evidence.
Does Gateway replace Splunk, Datadog, Elastic, Azure Monitor, or Sentinel?
No. Those platforms remain downstream. Cerbi governs telemetry before it reaches them.
Does Cerbi receive raw customer telemetry?
Cerbi does not operate a hosted raw-log relay for Gateway. Processing and forwarding occur in the customer environment; CerbiShield retains bounded governance and operational evidence rather than serving as the raw telemetry destination.
What throughput does Gateway support?
A live v1.10.80 baseline sustained 19.1K–19.5K events/sec with 50-event OTLP/HTTP batches on one 0.5-vCPU, 1-GiB replica in observe mode. Normalized, that is approximately 38K events/sec or 10.2 MiB/sec per vCPU—useful sizing perspective, not proof of linear scaling. Every measured request returned HTTP 200. This was a bounded benchmark with the dormant debug exporter, not a plan-wide capacity promise or downstream-forwarding SLA. Payload, policy, batching, destination, and scale settings materially change throughput.
Is Gateway generally available?
Gateway is available as an optional CerbiShield enforcement path. It deploys dormant by default and exposes no public OTLP ingress until a customer explicitly configures the route, approved source boundary, and downstream destination.
Customer-controlled activation
Prove one real OTLP control in your own Azure environment.
Gateway remains dormant until you configure it. Start with a bounded workload, one representative policy decision, downstream verification, and the evidence needed to explain what happened.