Technical Architecture

How Cerbi Works

Cerbi adds a governance layer to your existing telemetry pipeline without replacing any of it. Your loggers, sinks, and observability platforms all continue to work exactly as before — Cerbi governs what reaches them.

Core principles

Zero-overhead on the hot path

CerbiStream intercepts log events in-process using the logging abstraction layer. Governance validation, field redaction, and schema checks all complete synchronously — with no network calls, no side-car processes, and no impact on your application's response time.

Async governance, never blocking

Violation detection, scoring, and reporting are dispatched to an internal queue and processed asynchronously. Your logger returns immediately. CerbiShield aggregates reports in the background without coupling your application to the governance plane.

Observability-platform agnostic

Cerbi sits between your logger and your destination. It does not replace Splunk, Datadog, or Azure Monitor — it governs what reaches them. Your existing dashboards, alerts, and retention policies remain untouched.

Tenant-hosted, data never leaves

Both CerbiStream (runtime) and CerbiShield (control plane) deploy inside your infrastructure. Cerbi does not process, store, or have access to your log data. Every governance decision happens on your hardware.

The problem Cerbi solves

Without governance, every log event your application emits travels directly to your observability sink unchecked. Sensitive fields — user emails, auth tokens, health data — land in Splunk or Datadog in plain text. Schema drift goes undetected until a dashboard breaks or an audit fails. Cerbi intercepts that flow and enforces rules before anything reaches the sink.

Before vs. After Cerbi

What changes when you add Cerbi to your telemetry pipeline

Without Cerbi

Application boundary

LoggerSerilog / MEL / NLog

Raw / unchecked logs

Splunk / Datadogreceives everything

PII / PHI can leak to the sink
Schema drift goes undetected
Governance is reactive — incidents first

With Cerbi

Application boundary

LoggerSerilog / MEL / NLog

CerbiStreamintercepts + governs

hot path — in-process

Sanitized logs

Splunk / Datadogreceives clean logs only

Async / non-blocking

Queueasync buffer

CerbiShielddashboard

Sensitive fields redacted before emission
Schema validated inline, drift prevented
Proactive governance with live scoring

Incidents first

Issues stopped at source

Sink gets raw data

Sink gets clean logs

Reactive governance

Proactive governance

Lifecycle of a governed log event

Cerbi operates at two points in your development lifecycle: at build time via the Roslyn analyzer, and at runtime inside your application process. Here is every step — and which are synchronous vs. async.

Build-time validation

The CerbiStream Roslyn analyzer runs during your standard dotnet build. It flags governance violations — missing required fields, disallowed fields — as diagnostics before anything ships. Fail fast, fix early.

App emits a log event

Your application calls its logger as normal — MEL, Serilog, NLog, or any ILogger implementation. No call-site rewrites are required.

CerbiStream intercepts

The CerbiStream provider intercepts the event before it reaches any output. This is in-process — there is no proxy, no agent, and no additional network hop.

Schema validation

The event is validated against the JSON governance profile active for that environment. Missing required fields and disallowed fields are flagged immediately.

Field blocking and masking

Fields marked as sensitive in the governance profile — PII, PHI, credentials — are blocked or masked before the event is forwarded. Nothing sensitive continues downstream.

Governance tagging and scoring

The event is tagged with governance metadata (profile applied, violations, redactions). Violations are queued asynchronously for CerbiShield — this never blocks event emission.

Clean event forwarded

The governed, tagged event is forwarded to your configured sink. Splunk, Datadog, Azure Monitor, Elastic, Seq, OTEL, and others receive only governed data.

Runtime flow diagram

The hot path (blue) is entirely in-process — no network calls, no agent, no proxy. The async governance path (orange) branches off CerbiStream and never blocks event emission. Both paths are shown below as they actually execute at runtime.

Runtime Flow

How a log event travels through Cerbi at emission time

Hot path — in-process, <1 ms overhead

Application boundary

Your Appemits log event

log event

LoggerSerilog / MEL / NLog

raw event

CerbiStreamintercepts + governs

sanitized

Splunk / Datadogobservability sink

async branch

Async governance path — non-blocking, off hot path

Governance Libvalidate + score

violations

Queueasync buffer

report

CerbiShieldcontrol plane dashboard

Synchronous hot pathAsync governance pathCerbi-owned componentno network calls on hot path

Hot path guarantee

CerbiStream validates and redacts the event synchronously before forwarding it. The entire operation runs in-process with no I/O. Overhead is consistently under 1 ms regardless of governance profile complexity.

Async governance guarantee

Violation detection and scoring are dispatched to an internal queue immediately after the event is forwarded. CerbiShield consumes this queue in the background. Your application never waits for governance reporting to complete.

Platform placement in your stack

Cerbi occupies a single layer in your telemetry stack — between your logger and your observability platforms. Nothing above or below it needs to change. You keep your existing Splunk dashboards, Datadog monitors, and log retention policies exactly as they are.

Your Application

Services generating telemetry

Logger

MEL / Serilog / NLog

CerbiStream

Governance layer — in-process

Observability Platforms

Splunk, Datadog, Azure Monitor, Elastic, OTEL, Seq

Key point: Cerbi governs telemetry before it reaches observability platforms. Your existing dashboards, alerts, and workflows remain unchanged.

Governance control plane — CerbiShield

CerbiShield is the web-based control plane you deploy into your tenant. It is where engineering and compliance teams author governance rules, validate them against real event shapes, deploy them to environments, and monitor the health of your telemetry pipeline in real time.

Define governance profiles

Write and version JSON-based governance rules that declare required fields, sensitive field patterns, enforcement modes, field aliases, and encryption configuration per environment.

Validate before deployment

Paste any log payload into the real-time validation console to confirm masking, blocking, and rule behavior before rollout — without touching production.

Deploy to environments

Push rule sets to specific environments (dev, staging, prod) independently. Deployment status, operator, and timestamp are tracked in the Deploy Center.

Monitor violations in real time

Live dashboard showing violation count, critical/error/warning breakdown, top violated rules, severity distribution, and 14-day trend.

Immutable audit trail

Every rule change, deployment action, and administrative event is recorded in an append-only audit log with actor, timestamp, and full activity history.

CerbiShield runs in your tenant. Cerbi does not process, store, or have access to your log data pipelines.

Security model

Cerbi is designed for enterprise environments where data residency, access control, and auditability are non-negotiable. Every component runs in your infrastructure, and every action is traceable.

Tenant-hosted deployment

Cerbi runs inside your infrastructure. We have no access to your log data at any point.

Role-based access control

Separate roles for rule authors, deployment operators, and read-only auditors across CerbiShield.

Microsoft Entra SSO

Enterprise single sign-on via Entra ID (formerly Azure AD). No separate Cerbi identity store.

Immutable audit logs

Append-only record of every rule change, deployment, and administrative action with full actor context.

Rule deployment tracking

Version-controlled rule sets with full visibility into which version is active in which environment at any time.

Observability platform compatibility

Cerbi is not an observability platform — it is a governance layer that sits in front of them. Any platform that accepts structured log events from a supported logger is compatible. The list below covers the most common enterprise deployments.

Splunk

Datadog

Azure Monitor

Elastic

OTEL

Seq

Any destination that accepts structured log events from MEL, Serilog, or NLog is compatible. Cerbi does not replace these platforms — it governs what reaches them.

Key concepts

A reference for the terms used throughout this documentation and in the CerbiShield interface.

CerbiStreamThe runtime enforcement engine — a package that plugs into your logger as a provider. All governance logic runs here, in-process.

CerbiShieldThe governance control plane — a tenant-hosted web application for authoring rules, validating payloads, managing deployments, reviewing violations, and monitoring posture.

Governance ProfileA JSON configuration (cerbi.json) that defines required fields, disallowed fields, field severities, enforcement mode, field alias mappings, and encryption configuration for a given environment.

ViolationAn event that contains a disallowed field, is missing a required field, or triggers a Forbidden severity rule. Tagged and reported asynchronously — never blocking.

Hot pathThe synchronous, in-process path that a log event takes from emission through CerbiStream to the observability sink. No I/O, no network calls.

Async governance pathThe non-blocking branch where violations and governance tags are queued and forwarded to CerbiShield. Completely decoupled from the hot path.

Enforcement modeStrict, Warn, or Audit — controls whether violations block an event, emit a warning, or are silently recorded. Configured per environment in CerbiShield.

Field AliasA mapping from a canonical field name to one or more alternative names used across services. Alias resolution lets a single governance rule apply across inconsistent naming conventions.

Encryption ConfigurationGovernance profile settings that define which fields require encryption and how those rules are enforced before events reach observability platforms.

Scoring ConfigurationGovernance profile settings that define how governance scores are calculated, including configurable weights, thresholds, and category emphasis.

Dual telemetry isolation

Each customer deployment keeps its operational telemetry in the customer's Azure subscription. A separate health-only telemetry channel can report limited platform health signals back to Cerbi without sending log payloads, governance content, or sensitive data outside the tenant.

Customer telemetry stays in tenant

All log events, governance decisions, and violation records remain inside your Azure subscription. Cerbi has no access to this data.

Health-only outbound channel

A separate, limited channel can send platform health signals to Cerbi — response times, uptime, service availability. No log content, no governance data.

No payload leaves the tenant

Log content, governance profile definitions, and sensitive field data do not travel through the health channel. The separation is enforced at the architecture level.

Multi-region deployment

CerbiShield can support multi-region deployment patterns with a primary control plane and regional runtime enforcement closer to workloads. This helps reduce latency and support regional deployment requirements without fragmenting governance control.

Primary control plane

A single control plane region manages governance profile authoring, deployment history, audit trails, and violation aggregation. All governance decisions are authored here.

Regional runtime enforcement

Satellite regions can host CerbiStream enforcement closer to workloads. Governance profiles are distributed from the primary control plane — reducing latency without splitting governance ownership.

Governance policy is always authored and versioned centrally. Regional deployments receive profiles from the primary control plane — governance control is never fragmented across regions.

Ready to add governance to your telemetry?

Start with CerbiStream in your application and connect to CerbiShield for centralized governance, monitoring, and compliance reporting.

View Pricing View on GitHub