Logging + OpenTelemetry governance

Govern what getslogged.

Cerbi governs risky logging inside the application or at the OTLP boundary, applying policy before sensitive telemetry spreads while keeping the observability stack you already use.

Run ScannerSee how it works

Built to fit the estate you already have

CerbiStream in-process
Gateway at the OTLP boundary
Existing destinations stay
94.7K+NuGet downloads
30Published packages
AzureMarketplace

CerbiShield product proof

August 2026 release-preview UI

Product preview
CerbiShield Governance Command Center August 2026 release-preview screen

Policy trace

Raw → decision → governed

Raw

user.email

maya.chen@example.com

REDACT

Governed

REDACT

[REDACTED]

The control boundary

Keep the stack · add the policy

Application

SDK / OTLP

Cerbi policy

Decide · transform

Observability

Existing stack

Before policy / after policy

See what was there.Move through what Cerbi removed.

The governed record stays visible. Move your pointer across the telemetry and the area beneath it reveals the original value Cerbi saw before policy. Nothing to click or drag.

REDACT

Replace sensitive content

DROP

Remove an unsafe field

ALLOW

Leave safe telemetry alone

Governed telemetryMove to reveal before policy
01PII / user.email
REDACT
user.email = "[REDACTED]"
02Secret / authorization
DROP
authorization = [DROPPED]
03Context / customer.ip
REDACT
customer.ip = "[REDACTED]"
04Allowed / trace_id
ALLOW
trace_id = "2f6c0e79d4054b11"
Governed by default · raw only under the reveal

01 / Discover

Find the risky log calls first.

Cerbi Scanner gives engineering and security teams a read-only view of sensitive fields, credential-like logging, schema problems, and high-cardinality risk before runtime changes are discussed.

Run in GitHub ActionsSee Scanner

No account · no source upload by default · report-only first

Example findings
Scanner 1.1.0
CERBI003password

Structured field is not allowed

CERBI001email

Sensitive data may be written to logs

CARDINALITYsessionId

High-cardinality field may increase ingest cost

02 / Enforce

Choose where policy executes.

Cerbi has two enforcement boundaries because application estates are not uniform. Use the one that matches the workload instead of forcing a migration.

OTLP boundary

Cerbi Gateway

Product details

For estates already emitting OpenTelemetry.

OTLP workloads route through a customer-hosted governance boundary, then continue to the observability destinations you already use.

01

OTLP workloads

02

Cerbi Gateway

03

Existing collector / backend

04

Observability

No Cerbi SDK in emitting workloadsCustomer-hosted Azure boundaryBest for lower-friction estate adoption
CerbiShield

03 / Operate

Keep the control and the evidence together.

CerbiShield manages policy, targets, rollout state, violations, audit history, and evidence. It does not replace the observability destination and it does not need to warehouse raw logs to show governance posture.

CerbiShield product proof
Release-preview UI
CerbiShield Governance Command Center release-preview screen

See where control is active and where attention is needed.

04 / Prove

Prove one workload before you expand.

A first evaluation should answer a technical question, not create a transformation program.

Run the free Scanner Plan one workload
01Scan one repositoryFind a real logging risk in code you already own.
02Choose one boundaryUse CerbiStream in-process or Gateway on an existing OTLP path.
03Verify downstreamConfirm the governed event reaches the destination in the expected form.
04Review the evidenceFinish with the policy, rollout, violation, and operating record.