Cut Datadog log ingest costs by governing what you emit, not what youship.
Datadog charges by ingested volume. Verbose debug logs, duplicate events, and structurally invalid entries all count. Cerbi filters them at emission time - inside your application - before the Datadog agent ever sees them.
The problem
Datadog ingest costs grow with application noise, not just application traffic
Debug-level events emitted in production, repeated health-check logs, exception stack traces with sensitive fields, and schema-inconsistent events all inflate your Datadog bill. Datadog Pipelines can drop events after ingestion, but you are already charged for bytes received by the agent. The only way to avoid the cost is to stop the events before they leave your application.
Before and after
// Governance runs at emission time, inside the application process. The sink receives only governed output.
Architecture
Filter before the Datadog agent, not inside it
CerbiStream intercepts log events before they reach the Datadog agent or Datadog SDK. Events that match drop rules (e.g. debug level in production, health-check events, known noisy patterns) never enter the agent buffer. You pay for what is worth indexing.
Your application
emits log events
Logger framework
MEL / Serilog / NLog
CerbiStream
filters at emission time
Datadog Agent
receives filtered output
Datadog
indexes governed events only
// Cerbi runs inside your process. No sidecar, no agent, no additional network hop.
Why existing tools are too late
Datadog Pipelines reduce retention cost, not ingest cost
Ingest billing happens at agent receipt
Datadog bills on bytes ingested into the platform, not on bytes retained after processing. Pipelines that drop events after ingestion save on storage, but not on the ingest charge itself.
Exclusion filters still ingest the event first
Datadog Log Exclusion Filters drop events after they have been received and processed by the Datadog backend. The bytes still count toward your ingested volume.
Application noise is a developer problem, not a platform problem
Verbose debug logging, repeated health-check events, and exception dumps are best controlled at the source by the team that writes the application code, not by pipeline operators after the fact.
How Cerbi fits with your stack
Works with the Datadog agent and Datadog SDK without changes
No changes to Datadog configuration
Cerbi governs events before they reach the agent. Your existing Datadog agent config, tags, and forwarding rules are unaffected.
Drop rules by level, event type, or field
Define which event types, severity levels, or field patterns should be dropped before emission. Rules live in cerbi_governance.json.
Works with all Datadog-compatible sinks
Serilog Datadog sink, MEL Datadog provider, and NLog Datadog target all receive governed output from CerbiStream.
Governance scoring via CerbiShield
CerbiShield shows which services are emitting the most governance violations and filtered volume, helping platform teams identify cost-reduction opportunities.
Common questions
Frequently asked
Stop Datadog ingest costs 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