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.
Editorial analysis by NHI Mgmt Group, based on content published by Sawmills: “Log Collection: Vector vs OTel Collector for DevOps Teams”.
Key questions
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: Why can log collectors create security risk if they are misconfigured?
A: Because log streams often carry sensitive fields such as tokens, authorization headers and customer data.
Q: How do you know if a telemetry pipeline is failing security governance?
A: Look for broken event chains, missing identity context, stalled investigations, and a growing need to replay data from cold storage.
Practitioner guidance
- Define telemetry classes before selecting a collector Separate audit logs, customer-impacting errors and routine noise from the start, then map each class to its own retention, redaction and buffering rule set.
- Test redaction rules against live log samples Run the exact parsing and masking rules against production-like records that contain authorization headers, tokens and nested JSON fields before rollout.
- Choose a collector model that matches your operating burden Use Vector when frequent log shaping and edge filtering dominate, and use OTel Collector when cross-signal standardisation and shared governance matter more.
Bottom line: Vector and OpenTelemetry Collector both solve log collection, but they optimise for different operating models and control burdens.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:23 pm
Pipeline governance is now a data protection control, not a tooling preference. Log collectors decide whether sensitive fields are redacted, whether low-value telemetry is dropped and whether critical evidence survives downstream pressure. In practice, that makes the collector layer part of security governance rather than an implementation detail. Teams should treat observability pipeline design as a control surface.
A question worth separating out:
Q: When should platform teams standardise telemetry across signals instead of optimising for logs only?
A: Standardise when multiple teams need the same processing model for logs, metrics and traces, or when governance requires reusable controls across the estate. If one team owns a log-heavy workload with frequent parsing changes, a log-first model may be easier to operate without sacrificing control.
👉 Read our full editorial: Vector vs OTel Collector: what log-first teams should weigh