OpenTelemetry log governance
One logging policy lifecycle. A selected OTLP log
boundary.
CerbiShield manages policy, rollout, and evidence. Supported runtimes enforce inside selected applications; Gateway applies signed policy to explicitly routed OTLP logs. Traces and metrics are outside Gateway's current scope.
The problem
Does your existing Collector configuration meet the requirement?
OpenTelemetry processors can filter and transform records. Evaluate their control coverage and evidence first. Cerbi is relevant when application-focused policy ownership, versioning, rollout, or evidence remains a recurring gap.
Before and after
// Governance runs at emission time, inside the application process. The sink receives only governed output.
Architecture
Choose the supported enforcement path
The example below shows an application integration before export. Alternatively, route supported OTLP logs through Gateway. Configure and test the selected path; Cerbi does not govern every exporter or unconnected log stream.
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
Check coverage, policy, and evidence
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.
Review available control evidence
A Collector may satisfy your requirement. Check whether available records establish the policy, affected application, and observation window your reviewer needs.
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
Evaluate the integration your workload actually uses
.NET OTEL logging
CerbiStream wraps ILogger. The OTEL MEL bridge receives governed events. Verify the selected integration and exporter configuration.
Java OTEL logging
Use dedicated Cerbi Java integrations for supported Logback or Log4j2 logging paths; verify adapter behavior and export compatibility.
Go OTEL logging
Use a supported Cerbi Go integration and verify its policy actions and downstream log bridge behavior.
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
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