Notifications
Clear all
Topic starter
19/08/2026 3:46 pm
TL;DR: Vector and OpenTelemetry Collector both collect Kubernetes logs, but Sawmills argues the real decision is whether teams need log-first pipeline ergonomics or cross-signal standardisation across logs, metrics, and traces, with different tradeoffs in transformation language, operational complexity, and performance. The choice is less about raw capability than about which pipeline model your team can operate safely at scale.
NHIMG editorial — based on content published by Sawmills: All posts Log Collection: Vector vs OTel Collector for DevOps Teams
Questions worth separating out
Q: How should teams choose between Vector and OTel Collector for log collection?
A: Choose Vector when log parsing, filtering, and routing are the main problems and the team needs an easy-to-read edge pipeline.
Q: When does log processing become a governance issue rather than an engineering detail?
A: It becomes a governance issue when the pipeline determines whether security-relevant events are trustworthy, complete, and available for review.
Q: What do teams get wrong about telemetry pipeline performance?
A: They assume synthetic throughput numbers predict production behaviour.
Practitioner guidance
- Classify telemetry by business value Separate audit logs, error logs, and low-value noise before writing routing rules.
- Validate redaction and drop rules against live samples Test transforms on real logs before rollout, especially for nested auth headers, tokens, and noisy Kubernetes messages.
- Design per-stream durability policies Use blocking buffers for critical telemetry and more permissive behaviour for routine logs.
What's in the full article
Sawmills' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Vector and OTel Collector configuration examples for Kubernetes log pipelines
- Full benchmark comparisons across throughput, CPU, and memory under different workload conditions
- Production routing patterns for audit, error, and standard logs with different buffer behaviour
- Operational tips for choosing edge collection, gateway aggregation, or a hybrid model
👉 Read Sawmills' comparison of Vector and OTel Collector for log collection →
Vector vs OTel Collector for logs: are your controls keeping up?
Explore further
19/08/2026 4:23 pm
Log collection is now a control plane for evidence, not a plumbing choice. Once telemetry is filtered, redacted, and routed at the edge, the collector determines what investigators can later prove. That makes observability design relevant to incident response, auditability, and data minimisation in the same way access controls shape identity governance. Practitioners should treat collection rules as policy, not just configuration.
A question worth separating out:
A: Separate them immediately. Critical logs such as audit and high-severity error streams need stronger durability than routine telemetry, because a shared policy can either drop evidence or amplify backpressure into an outage. Distinct streams let teams preserve what matters without treating every event as equally important.
👉 Read our full editorial: Vector vs OTel Collector: what log-first teams should weigh
