There is a common false choice in log sanitization: either you sanitize with a CLI at the point of sharing, or you build a centralized pipeline that handles everything. In practice, many teams need both. They solve different problems, and treating them as alternatives leads to gaps in both directions.
What a CLI is good at
A CLI operates at the moment of sharing. An engineer pulls a log slice, runs it through the sanitizer, and sends the result. No infrastructure required, no platform dependency, no waiting.
That makes it the right tool for the human sharing path: support tickets, GitHub issues, vendor portals, Slack threads. These are all moments where a person is making a deliberate decision to send something outside the system. The CLI can be part of that decision — fast, local-first, and reviewable before anything leaves.
The other advantage is auditability. A CLI with deterministic output lets you run the same input twice and get the same result. You can commit the sanitized artifact, generate its hash, and later prove exactly what was shared. That is harder to do with a pipeline that transforms data in transit.
What centralized pipelines are good at
Pipelines operate at scale and at rest. They handle the storage and observability path: everything your systems emit automatically, all the time, routed to Elasticsearch, Datadog, Splunk, or wherever logs live.
A pipeline can enforce organization-wide policy without requiring every engineer to remember to run a command. It can apply DLP rules, mask fields based on sensitivity classification, alert when high-entropy strings appear in production logs, and enforce retention boundaries automatically.
The tradeoff is setup cost and trust. A pipeline is infrastructure — it needs to be built, maintained, monitored, and tested. And critically, a pipeline runs on data that has already left the originating system. By the time the pipeline processes a log, it has already been transmitted somewhere. If the pipeline fails or has coverage gaps, the fallback is raw data sitting unprotected in a buffer or a dead-letter queue.
Why you usually need both
The two approaches protect against different failure modes.
A CLI protects against logs leaving your system unsanitized via human action. A pipeline protects against logs sitting inside your system with insufficient access controls or retention limits.
If you only have a pipeline, the human sharing path remains unprotected. An engineer working an incident at midnight who pastes logs into a vendor chat is not going through the pipeline. If you only have a CLI, automated ingestion paths remain unprotected. Everything your systems emit continuously and ship to aggregators goes through with no coverage.
The combined approach is straightforward: use the pipeline to protect what you store and to catch issues at scale. Use the CLI to protect what you share, where a human is making a decision to cross a boundary.
A practical rule of thumb
If the risk is logs leaving your system — going to a vendor, a public forum, an external tool — prioritize local-first sanitization. Make the CLI the mandatory step before sharing, and make it fast enough that it does not slow people down.
If the risk is logs stored inside your system accumulating sensitive data over long retention windows — prioritize pipeline controls. Apply redaction and field masking before data lands in your aggregation layer, not after.
Neither replaces the other. Teams that treat this as an either/or decision tend to end up with good coverage on one path and blind spots on the other.
Next: common redaction mistakes. Most failures are not advanced — they are basic patterns that are easy to miss until they cause a real incident.