Elastic stores and searches your logs. Cerbi governs what those logscontain.
Elastic is a destination. Cerbi is a source-side control. They solve different problems at different points in your logging architecture. Used together, Elastic indexes clean, compliant, schema-valid log data.
The problem
Elasticsearch indexes whatever it receives
Elasticsearch is designed to ingest and index any structured or semi-structured data you send it. It does not inspect field values for PII, enforce required fields, or block non-compliant events. That is not what it is for. Governance has to happen before data reaches Logstash, Elastic Agent, or the Elasticsearch ingest pipeline.
Before and after
// Governance runs at emission time, inside the application process. The sink receives only governed output.
Architecture
Cerbi governs before Logstash or Elastic Agent
CerbiStream intercepts log events inside your application process. Governed output is what reaches Logstash, Elastic Agent, or the Elasticsearch Bulk API. Your index mappings, ILM policies, and Kibana dashboards all operate on clean data.
Application
emits log event
Logger framework
MEL / Serilog / NLog
CerbiStream
governs at emission
Logstash / Elastic Agent
ships governed output
Elasticsearch
indexes governed data
// Cerbi runs inside your process. No sidecar, no agent, no additional network hop.
Why existing tools are too late
Logstash filters and Elasticsearch ingest pipelines act after data arrives
Logstash filters run on data that has already left the application
Logstash's mutate, ruby, and drop filters can transform and remove fields, but only on events that have already been transmitted from the source application. Sensitive data has already crossed a network boundary before any Logstash filter executes.
Elasticsearch ingest pipelines process at index time, not at source
Ingest pipelines run on the Elasticsearch node when a document is indexed. The raw document - including any sensitive fields - has already been transmitted to the Elasticsearch cluster.
Elastic does not enforce application-level schemas
Elasticsearch can enforce field types via index mappings, but it does not prevent applications from emitting events with missing required fields or non-compliant structures. Schema enforcement has to happen at the source.
How Cerbi fits with your stack
Cerbi works with all Elastic-compatible log shippers
Works with Logstash
Serilog Logstash sink and NLog Logstash target receive governed output from CerbiStream. Logstash pipeline configuration does not change.
Works with Elastic Agent
Application logs governed by Cerbi are written to files or stdout. Elastic Agent collects governed output.
Works with Elasticsearch Bulk API
Direct-to-Elasticsearch sinks (e.g. Serilog.Sinks.Elasticsearch) receive governed events from CerbiStream.
Kibana dashboards stay accurate
When required fields are enforced at emission time, Kibana dashboards built on those fields always have data to display.
Reduces Elasticsearch storage cost
Filtering verbose and non-compliant events at emission time reduces the volume indexed by Elasticsearch.
Complements ECS (Elastic Common Schema)
Use Cerbi governance rules to enforce ECS-required fields (event.kind, service.name, trace.id) at emission time.
Comparison
Cerbi vs Elastic - governance capabilities
| Capability | Cerbi | Elastic Stack |
|---|---|---|
| In-process PII / PHI redaction | - | |
| Source-side log governance | - | |
| Post-ingestion field redaction Data has already reached Elasticsearch at that point | - | Ingest pipelines |
| Log search and analytics | - | |
| Required field enforcement at emission | - | |
| Kibana dashboards | - | |
| Policy as code (cerbi_governance.json) | - | |
| CI / CD governance validation | - | |
| Enforces ECS fields at source Elastic enforces field types at index, not at emission | - | |
| Deployed in your Azure subscription | - |
Common questions
Frequently asked
Stop sensitive data reaching Elasticsearch 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