Schema governance
Enforce log schemas at emission time. Not as a
suggestion.
Inconsistent log schemas break dashboards, corrupt alert rules, and make incident response slower. Cerbi enforces required fields and structural rules in-process, before log events reach any sink.
The problem
Log schema drift is invisible until something breaks
Teams agree on a canonical log shape. Then a new service ships without a correlationId. A refactor removes the tenantId field. An exception handler logs a different severity level than the policy specifies. None of these are caught until a dashboard breaks, an alert fires incorrectly, or an audit query returns incomplete results.
Before and after
// Governance runs at emission time, inside the application process. The sink receives only governed output.
Architecture
Schema rules are evaluated before the event leaves your process
CerbiStream validates each log event against your cerbi_governance.json profile. Missing required fields can be flagged as violations or cause the event to be dropped. Disallowed fields are removed. The Cerbi Scanner ADO extension validates profile conformance in CI before code ships.
Service A / B / C
emit log events
Logger framework
MEL / Serilog / NLog
CerbiStream
validates schema at emission
Datadog / Splunk
receives schema-valid events
// Cerbi runs inside your process. No sidecar, no agent, no additional network hop.
Why existing tools are too late
Schema validation at the sink is too late to prevent noise
Invalid events reach the index before you know they are invalid
Log management platforms ingest events first and parse them second. By the time a missing field causes a dashboard gap, thousands of non-conforming events are already in the index.
Linting tools only check code, not runtime output
Static analysis can check that a log call has the right arguments, but it cannot evaluate the runtime value of structured fields or detect fields added by middleware and framework instrumentation.
Cross-service schema drift is invisible in CI
Each service may pass its own unit tests while emitting log shapes that differ from what the platform team expects. Without emission-time validation, drift accumulates silently.
How Cerbi fits with your stack
Governance rules live alongside your code and are enforced at runtime
Required fields enforcement
Specify fields that must exist on every log event. Violations are flagged with a governance record. Events can be blocked or allowed with a violation tag.
Disallowed field blocking
Configured disallowed fields can be removed on supported integrated paths. Fields or paths outside that boundary require separate controls.
Severity alignment
Cerbi can enforce that specific event types use the correct severity level, preventing debug-level noise from appearing as production warnings.
CI validation via Cerbi Scanner
The Azure DevOps extension validates your governance profile against actual log output shapes during the build pipeline, before code ships.
Policy versioning
cerbi_governance.json is version-controlled. Policy changes are audited. CerbiShield tracks drift from the committed policy baseline.
Multi-service consistency
One governance profile can be shared across services via a shared NuGet or PyPI package, enforcing consistent schemas without per-service configuration.
Common questions
Frequently asked
Review the logging-control gap
Bring a logging finding or evidence requirement. Compare existing controls, then scope one CerbiShield workload and policy if a recurring gap remains.
// local demo path: install from NuGet, PyPI, Maven, or the Go module registry - no account required