Govern log events before they enter the OpenTelemetrypipeline.
The OTEL collector processes what your application emits. Cerbi governs what your application emits. By the time your LogRecord reaches the collector, it is already clean, schema-valid, and free of sensitive fields.
The problem
OTEL collectors forward what they receive - they do not govern it
OpenTelemetry collectors can filter, transform, and route telemetry data. But they operate on what arrives from your application SDK. If your app emits a log event with an email address, a JWT, or an internal identifier, the OTEL SDK packages it into a LogRecord and the collector receives it. Governance needs to happen before the OTEL SDK, not after.
Before and after
// Governance runs at emission time, inside the application process. The sink receives only governed output.
Architecture
Cerbi runs before the OTEL SDK constructs the LogRecord
CerbiStream wraps your logging framework (MEL, Serilog, NLog) at the ILogger or LogManager level. Governance runs before the event is handed to the OTEL log exporter. The exporter receives only governed output. Your collector, backend, and trace correlation are unaffected.
Application code
emits log event
MEL / Serilog
logger framework
CerbiStream
governs before OTEL SDK
OTEL SDK / Exporter
packages LogRecord
OTEL Collector
routes governed output
// Cerbi runs inside your process. No sidecar, no agent, no additional network hop.
Why existing tools are too late
OTEL processor pipelines run after the LogRecord is constructed
LogRecord attributes are set before the processor pipeline sees them
OTEL log processors receive a complete LogRecord. The sensitive field is already a named attribute inside the record. Processor transforms can remove or mask attributes, but the data has already been serialised by the SDK.
Collector-level filtering is not audit-friendly
Applying sensitive-field redaction in the collector creates a gap between what was emitted and what was received. Compliance auditors often require evidence that the field was never transmitted, not just that it was removed in transit.
OTEL semantic conventions do not enforce security
OpenTelemetry defines naming conventions for log attributes but does not enforce which fields may or may not appear in a log event. That is a governance layer responsibility.
How Cerbi fits with your stack
Cerbi integrates with the .NET, Java, Go, and Python OTEL stacks
.NET OTEL logging
CerbiStream wraps ILogger. The OTEL MEL bridge receives governed events. No changes to your AddOpenTelemetry() setup.
Java OTEL logging
CerbiStream for Java wraps Logback or Log4j2. The OTEL log bridge appender receives governed output.
Go OTEL logging
CerbiStream for Go wraps slog or zap. The OTEL log bridge receives governed output.
Trace correlation preserved
Cerbi governs log fields, not trace context. TraceId, SpanId, and trace flags pass through unchanged.
Works with any OTEL backend
Whether you export to Grafana, Honeycomb, Datadog OTLP, or your own collector, the governed output is what the backend indexes.
Schema enforcement alongside security
Use the same governance profile to require OTEL-standard fields (traceId, spanId, service.name) on every log event.
Common questions
Frequently asked
Stop ungoverned OTEL log events 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