Telemetry processing
What happens to the event?
Receive, filter, redact, transform, enrich, sample, route, buffer, or export telemetry. This is a real technical capability that many open-source and commercial tools provide well.
Architecture guide / not a battlecard
Choose the control model before choosing the product.
There are several legitimate places to process telemetry. This guide separates where a control executes from who owns the governance lifecycle around it.
01The distinction
Telemetry governance
Who owns the decision over time?
Define policy, assign targets, validate behavior, control rollout, investigate violations, record exceptions, retain evidence, and explain the control after deployment.
02Architecture matrix
| Approach | Control executes | Strong at | What you operate | Governance lifecycle |
|---|---|---|---|---|
Logger / framework filters | Inside application code | Earliest local transformation and full application context. | Per-language libraries, configuration, rollout, tests, and evidence conventions. | Team-built |
OpenTelemetry Collector | Agent, sidecar, gateway, or collector tier | Open, vendor-neutral receiving, processing, transformation, filtering, and export. | Collector configuration, processor behavior, rollout, scaling, policy conventions, and evidence model. | Team-built |
Telemetry pipeline platforms | Pipeline / edge / worker tier | Large-scale routing, reduction, enrichment, transformation, and destination control. | Commercial platform plus its data-processing and routing model. | Varies by platform |
Destination-side controls | At or inside analytics / SIEM / observability destination | Masking, retention, indexing, access, and downstream analytics controls close to storage and query. | Destination-specific policies and administrative controls. | Destination-specific |
Cerbi | Application boundary or customer-hosted OTLP boundary | Discovery plus an explicit governance lifecycle around policy, targeting, enforcement, investigation, and evidence. | CerbiShield control/evidence plane plus selected Stream or Gateway enforcement path. | Built into the product model |
The point is not that one architecture wins every row. The point is to identify which responsibility your team wants to buy, which it wants to build, and where sensitive telemetry should be governed in your environment.
03Decision questions
Use questions that change architecture.
These are more useful than counting checkmarks because each answer changes the boundary, integration effort, or operating ownership.
Where should the control execute?
If the strongest requirement is closest-to-emission control and you can change the application, an in-process approach is compelling. If workloads already emit OTLP and application integration is the friction, a gateway boundary can be the better tradeoff.
Is processing the same as governance?
No. Processing is the act of transforming, filtering, or routing telemetry. Governance adds the lifecycle around the decision: policy ownership, versioning, targets, rollout, exceptions, investigation, evidence, and audit.
Do commercial pipelines become competitors?
They overlap where telemetry is transformed before a destination. Their broader center of gravity is typically data routing, reduction, enrichment, and optimization. Cerbi is intentionally narrower around the governance lifecycle.
Does Cerbi replace OpenTelemetry?
No. Cerbi Gateway is designed for existing OTLP estates and keeps OpenTelemetry-compatible telemetry moving to the customer's current destination. The Collector remains a valid and powerful processing substrate.
Does Cerbi replace Splunk or Datadog?
No. Search, dashboards, SIEM, APM, alerting, retention, and analytics remain downstream responsibilities. Cerbi governs selected telemetry before it continues there.
04Cerbi fit
Cerbi is the lifecycle around selected telemetry controls.
Scanner discovers risk. CerbiShield owns policy and evidence. CerbiStream or Gateway enforces at the selected boundary. Existing observability remains downstream.
- No requirement to replace your logger or observability backend.
- No requirement that every workload use the same enforcement path.
- No Cerbi-hosted raw-log relay as the core architecture.
- No claim that OpenTelemetry or telemetry pipelines cannot transform data.
01 / Discover
Scanner
02 / Govern
CerbiShield
03 / Enforce
Stream / Gateway
04 / Prove
Evidence
Still deciding?
Prove the boundary with one workload.
The useful next step is not a generic demo. Pick one real logging risk and test the control model that fits your architecture.