Notifications
Clear all
Topic starter
19/08/2026 3:37 pm
TL;DR: Kubernetes log aggregation succeeds or fails on pipeline design, not on the choice of EFK, Loki, or another backend, according to Sawmills. The core issue is that node-level log collection, metadata enrichment, sampling, and filtering become a policy problem once clusters grow and log volume spikes.
NHIMG editorial — based on content published by Sawmills: Log aggregation in Kubernetes: the pipeline that survives 5,000 pods, not the tool that demos well at 50
Questions worth separating out
Q: How should teams govern Kubernetes log aggregation at scale?
A: Teams should treat log aggregation as a policy problem, not a backend selection exercise.
Q: Why does Kubernetes log aggregation become expensive so quickly?
A: Costs rise when enrichment and retention are left unchecked.
Q: What breaks when log collectors lose track of rotated files?
A: Collectors can duplicate lines, skip events, or miss the exact incident window you need most.
Practitioner guidance
- Define collection policy before selecting a backend Decide which log classes deserve hot retention, which should be sampled, and which should be dropped at the node before the pipeline reaches a searchable store.
- Scope collector RBAC to metadata only Give the collector just enough access to enrich logs with namespace, pod, deployment, and node data, and verify the service account cannot drift into broader cluster privileges.
- Limit high-cardinality labels at ingestion Block or strip attributes such as pod name and other restart-prone fields unless they are required for incident response.
What's in the full article
Sawmills's full article covers the operational detail this post intentionally leaves for the source:
- Node-by-node collector patterns for Kubernetes clusters that need to survive pod churn and log rotation
- OpenTelemetry filelog configuration examples, including the k8sattributes processor and RBAC requirements
- Gateway-level policy enforcement ideas for drop, sample, redact, and route decisions
- A comparison of backend trade-offs between label-indexed and content-indexed log platforms
👉 Read Sawmills's analysis of Kubernetes log aggregation at scale →
Kubernetes log aggregation at scale: where the governance gap appears?
Explore further
19/08/2026 4:17 pm
Log aggregation becomes a policy enforcement problem once Kubernetes scale introduces telemetry sprawl. The article is right to de-emphasise the backend choice, because the real failure mode is upstream: teams ingest far more than they can justify, then try to fix it after the cost and noise have compounded. In practice, that makes the pipeline itself the governance boundary for what deserves retention, routing, and redaction. The practitioner takeaway is to enforce telemetry policy where the data enters the platform, not where it is queried later.
A question worth separating out:
Q: Who should own log aggregation policy in Kubernetes?
A: The platform team should own aggregation policy because the rules apply across services, not inside a single application. Developers can emit logs, but platform owners should decide retention, sampling, routing, and redaction standards. That keeps the control consistent as the cluster grows and prevents each service from creating its own logging cost profile.
👉 Read our full editorial: Kubernetes log aggregation fails at scale when policy stays implicit
