Cerbi and Datadog Observability Pipelines
Compare the control. Then compare the
evidence.
Datadog Observability Pipelines can process logs in your environment, including sensitive-data redaction before logs leave your premises. Evaluate that capability against your logging-control and evidence requirements.
The problem
Does a material logging-control gap remain?
Start with one requirement: a sensitive field, inconsistent policy across application teams, or evidence needed for a customer review. Test existing controls first. Cerbi is relevant when application-focused policy, rollout, or evidence remains inadequately covered.
Before and after
// Governance runs at emission time, inside the application process. The sink receives only governed output.
Architecture
Select and test the boundary
CerbiStream applies policy inside integrated applications. Cerbi Gateway applies policy to explicitly routed OTLP logs. CerbiShield manages policy and recorded evidence in your Azure tenant. Neither path governs unconnected logging. The sequence below illustrates one possible application path, not a required deployment.
Selected application
supported logging integration
CerbiStream
configured logging policy
Datadog Observability Pipelines
existing processing or destination
// Cerbi runs inside your process. No sidecar, no agent, no additional network hop.
Why existing tools are too late
Questions to test in your environment
Coverage
Which paths are connected, and which can bypass the control? Check field formats, runtime integration, and configuration rather than assuming complete coverage.
Policy operation
Who owns the policy, how is it versioned and rolled out, and how are exceptions and failed deployments reviewed?
Evidence
Can you connect a recorded outcome to an application, policy version, and observation window? Identify missing context and retention requirements.
How Cerbi fits with your stack
Evaluate an ongoing logging-policy lifecycle
Discover
Use the free Scanner independently to identify potential logging risks in source and CI.
Define policy
Where a recurring gap remains, use CerbiShield to manage versioned policy and selected targets.
Enforce
Test supported actions on one application or OTLP log path. Validate the result and operational overhead.
Prove
Review available outcomes, rollout, exceptions, and audit evidence before deciding on a recurring deployment.
Comparison
Compare against your requirement
| Capability | Cerbi | Datadog Observability Pipelines |
|---|---|---|
| Sensitive-field processing | Configured actions on supported logging paths | Sensitive Data Scanner processor in an Observability Pipelines Worker |
| Logging policy and evidence | CerbiShield policy, rollout, recorded outcomes, and audit | Evaluate available controls, records, and integrations |
| Integration and operation | Customer-hosted Azure services plus selected application or OTLP log integration | Depends on your existing deployment and configuration |
| Decision criterion | Evaluate when a material recurring gap remains | Retain existing controls when they satisfy the requirement |
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
Capability reference: Datadog Observability Pipelines documentation. Compare your deployed version, configuration, and terms.