A telemetry pipeline is the layer between your systems and your monitoring or security tools. It receives logs, metrics and traces, cleans and filters them, and sends them to one or more destinations. You need one when sending data straight from every service to every tool becomes costly, leaky or hard to change.
What are the parts of a pipeline?
The OpenTelemetry Collector is a useful reference because its documentation defines the model plainly. A pipeline has three kinds of component. Receivers collect data. Processors, which are optional, take data from receivers and change it. Exporters take data from processors and send it out. A pipeline works on one data type, traces, metrics or logs, and the same receiver or exporter can appear in several pipelines.
Beyond those, the Collector supports extensions that add capabilities such as health checks and diagnostics. Extensions do not need direct access to telemetry.
Other tools use different words, but the shape is the same: input, transform, output.
Why not send data straight to the backend?
For a small system, direct export is fine. OpenTelemetry's own guidance says that sending directly is a good way to get value quickly in development or small-scale environments. It recommends a collector alongside your service in general, because the service can hand off data fast and the collector handles retries, batching, encryption and filtering of sensitive data.
Three problems push teams toward a pipeline. Cost: every byte kept in an analytics tool is billed or stored, so dropping debug noise early saves money. Change: swapping a vendor means editing every service if each one exports on its own. Safety: applications log things they should not, and a central place to remove them is easier than fixing every code path.
What can processors do for security?
The Collector's configuration reference shows processors that match these jobs. An attributes processor can delete a key such as a database statement or hash a value such as an email address. A filter processor can drop records, including those whose body matches a pattern. A memory limiter protects the collector itself from overload, and a probabilistic sampler keeps a percentage of traces.
Those are useful for removing personal data and secrets before they reach long-term storage, and for keeping an alert flood from exhausting a collector. They are not a substitute for fixing the source that logs a password.
What are the risks of adding a pipeline?
A pipeline becomes a high-value component: it sees nearly everything. The OpenTelemetry docs carry a warning that example configurations bind to 0.0.0.0 for convenience and that endpoints should be bound to localhost when all clients are local. An open receiver on an internal network invites forged data or a denial of service. Other risks are silent data loss when queues fill, filters that quietly drop security-relevant events, and credentials for exporters stored in plain configuration files.
For security data, add one more concern: log integrity. If an attacker who gains access can alter or switch off the pipeline, the evidence goes with it.
A constructed example
A team runs thirty services, each shipping logs to a hosted analytics tool. Costs climb, and a review finds a service logging full request bodies with account numbers. They deploy a collector as a daemon on each node. Receivers accept data from local services only. A processor deletes the request body field and hashes the user email. A filter drops health-check logs. One exporter sends everything to the analytics tool, and a second sends only authentication and admin events to a separate store with restricted write access. They also set an alert for the collector's own dropped-data counters, so a failure is visible.
How to check or apply this
- List your telemetry sources and destinations and who owns each.
- Decide which fields must never leave the service, and enforce removal in the pipeline as a second line of defense.
- Bind receivers to the narrowest interface, and use authentication and encryption between hops.
- Route security-relevant events to a destination that the pipeline operators cannot rewrite.
- Monitor the pipeline itself for drops, queue depth and restarts.
- Version your pipeline configuration and review changes like code.
Quick check
Is a telemetry pipeline the same as a SIEM?
No. A pipeline moves and shapes data. A SIEM stores, correlates and alerts on it. Many teams place a pipeline in front of a SIEM to control volume and content.
Do processors replace fixing noisy or sensitive logging in the app?
No. They reduce exposure, but the safest fix is not to emit the data at all.
Sources
- OpenTelemetry Collector overview
- OpenTelemetry Collector architecture
- OpenTelemetry Collector configuration
Last reviewed: 18 October 2026.
