Cerbi vs Datadog Observability Pipelines

Datadog Observability Pipelines act after ingestion. Cerbi acts beforetransmission.

Datadog Observability Pipelines let you route, filter, and transform log events inside the Datadog platform. Cerbi governs log events inside your application process, before they reach the Datadog agent. These are different insertion points with different compliance implications.

The problem

Ingestion-time filtering still means Datadog received the raw event

Datadog Observability Pipelines can drop or transform events after they enter the Datadog platform. However, the raw event - including any sensitive fields - has already been transmitted from your application, received by the Datadog agent, and shipped to Datadog infrastructure. For GDPR, HIPAA, and PCI DSS purposes, transmission constitutes exposure.

Before and after

Without Cerbi
01
email="patient@hospital.org"PII
02
diagnosis="ICD-J45.909"PHI
03
event="AppointmentBooked"
04
traceId="7c9f1a2b3d4e5f6a"
With Cerbi
01
email="[REDACTED]"PII removed
02
diagnosis="[BLOCKED]"PHI blocked
03
event="AppointmentBooked"
04
traceId="7c9f1a2b3d4e5f6a"

// Governance runs at emission time, inside the application process. The sink receives only governed output.

Architecture

Two different positions in the data flow

Cerbi operates inside the application process before any network transmission. Datadog Observability Pipelines operate after the Datadog agent receives and forwards the event to Datadog infrastructure. For source-side governance, Cerbi is the only option.

Application

emits log event

CERBI

CerbiStream

governs at emission

Datadog Agent

forwards governed output

Datadog Pipelines

routes / transforms

// Cerbi runs inside your process. No sidecar, no agent, no additional network hop.

Why existing tools are too late

What Datadog Observability Pipelines cannot do

Events are already at Datadog before pipelines run

Datadog Observability Pipelines operate on events that have already been ingested by the Datadog platform. Source-side prevention requires a tool that runs in your application, not in Datadog's infrastructure.

Ingest billing applies before pipeline filtering

Datadog charges for events ingested by the agent. Pipeline filtering that drops events after ingestion reduces storage cost but does not reduce the ingest charge for the dropped events.

Pipeline rules are managed by the observability team, not the dev team

Governance rules defined in Datadog Pipelines are not co-located with application code. When a developer adds a new sensitive field, there is no automated mechanism to update the pipeline rule.

How Cerbi fits with your stack

Cerbi and Datadog Observability Pipelines address different layers

Cerbi: source-side governance

Prevent sensitive fields from leaving the application. Reduce volume before the agent. Enforce developer-owned schema rules.

Datadog Pipelines: platform-level routing

Route governed events to different indexes. Apply transformations for specific consumers. Archive a clean stream.

Complementary in practice

Use Cerbi to govern at the source. Use Datadog Pipelines for routing and any additional enrichment. The pipeline receives cleaner, lower-volume input.

No Datadog configuration changes needed to deploy Cerbi

CerbiStream or a plugin adapter slots into your application. The Datadog agent and pipeline configuration stay exactly as they are. Cerbi governs before the agent ever sees the event.

Comparison

Cerbi vs Datadog Observability Pipelines

CapabilityCerbiDatadog Pipelines
Governs before data leaves the application-
Governs after data reaches Datadog-
In-process PII / PHI redaction-
Post-ingestion event filtering-
Reduces Datadog ingest volume

Cerbi stops events before the agent. Pipelines filter after billing.

-
Enforces required log fields-
Schema-invalid event blocking-
Policy as code in the application repo-
Multi-destination routing-
Deployed in your Azure subscription-
Works independently of Datadog-

Common questions

Frequently asked

Stop sensitive data reaching Datadog 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

NEXTChoose your next proof

Use CerbiStream inside selected applications, Cerbi Gateway at the OpenTelemetry boundary, or both. CerbiShield keeps policy, rollout, violations, audit, and evidence under one governance program.

One initial workload/Customer-hosted in Azure/Existing destinations remain
Cerbi vs Datadog Observability Pipelines | Cerbi