Cribl processes what leaves your app. Cerbi governs what your appemits.
Both tools reduce log volume and enforce data policies. The difference is where in the pipeline that happens. Cribl operates on the collection layer after data has left your application. Cerbi operates inside the application process before any data is transmitted.
The problem
Pipeline governance cannot undo transmission
When sensitive data appears in a log event, the damage is proportional to how far it travels before it is stopped. An in-process governance check stops it before any network call. A pipeline check stops it after it has been serialised, transmitted, buffered, and received by at least one external service.
Before and after
// Governance runs at emission time, inside the application process. The sink receives only governed output.
Architecture
Different insertion points in the telemetry pipeline
Cerbi is an application library. It installs alongside your logger and runs inside your process. Cribl is a pipeline platform - it sits between your application outputs and your log destinations. The two tools solve different problems at different points in the data flow.
Application
emits log event
CerbiStream
governs at emission
Cribl / Pipeline
routes and transforms
Splunk / Datadog
final destination
// Cerbi runs inside your process. No sidecar, no agent, no additional network hop.
Why existing tools are too late
What Cribl does not solve
Data leaves the application before Cribl sees it
Cribl receives events from forwarders and agents. By the time a Cribl pipeline redacts a sensitive field, that field has already been written to disk, transmitted over the network, and received by the collection agent.
Cribl operates on the ops team's infrastructure, not the dev team's code
Configuring Cribl pipelines is typically an ops or platform engineering task. Cerbi governance rules live in cerbi_governance.json alongside application code, owned by the development team.
Cribl does not enforce logging schemas
Cribl can transform and filter event fields, but it does not enforce that events conform to a schema defined by the application team. Required fields, severity alignment, and structural rules are not Cribl's domain.
How Cerbi fits with your stack
Cerbi and Cribl are complementary, not competing
Cerbi reduces what Cribl has to process
Governance at emission means fewer events, smaller events, and no sensitive fields enter the Cribl pipeline. Cribl can focus on routing and enrichment.
Different ownership boundaries
Dev teams own Cerbi governance profiles. Ops teams own Cribl pipeline configuration. Each layer is managed by the right team.
Defense in depth
Running both means sensitive data is blocked at emission (Cerbi) and any residual noise is handled at routing (Cribl). Two checkpoints are better than one.
No Cribl configuration changes required
Deploying Cerbi does not require changes to your Cribl pipelines. Cerbi governs upstream. Cribl continues to operate as-is.
Comparison
Cerbi vs Cribl - capability comparison
| Capability | Cerbi | Cribl |
|---|---|---|
| Governs before data leaves the application | - | |
| Governs after data leaves the application | - | |
| In-process PII / PHI redaction | - | |
| Pipeline-level field transformation | - | |
| Enforces log schema (required fields) Cribl can drop/mask fields but not enforce required fields | - | |
| Works without infrastructure changes Cribl requires pipeline infrastructure | - | |
| Policy as code in the application repo | - | |
| CI / CD governance validation | - | |
| Multi-source routing | - | |
| Log format transformation | - | |
| Splunk, Datadog, S3 routing | - | |
| Deployed in your Azure subscription Cerbi control plane stays in your tenant | - |
Common questions
Frequently asked
Stop sensitive log data at the source
Install CerbiStream in under ten minutes. No infrastructure changes. No pipeline configuration. Governance runs inside your process from the first log event.
// local demo path: install from NuGet, PyPI, Maven, or the Go module registry - no account required