Notifications
Clear all
Topic starter
19/08/2026 3:39 pm
TL;DR: Kubernetes log management often fails because collection scales with pod count while cost scales with volume, retention, and indexing, and Sawmills’ analysis shows the real fix is deciding which logs should exist, where they should be processed, and what tier they belong in. The operational gap is governance, not collector choice, and the right policy can prevent noise from becoming a standing budget drain.
NHIMG editorial — based on content published by Sawmills: Kubernetes log management at scale: where the volume comes from and where to stop it
Questions worth separating out
Q: How should security teams control Kubernetes log volume without losing useful telemetry?
A: Start by removing low-value events at the source, then enforce node-local filtering, and finally route only useful classes to the right retention tier.
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 severity is not defined consistently across teams?
A: Routing, sampling, and retention rules all lose reliability.
Practitioner guidance
- Define log creation rules at source Classify health checks, probe traffic, and success-path lifecycle events in application standards so noisy lines are never emitted in production by default.
- Enforce node-local drop rules Apply filter logic in the DaemonSet agent for /healthz, /readyz, and known probe patterns so low-value logs do not reach the gateway or backend.
- Standardise severity semantics Document what debug, info, warn, error, and fatal mean in engineering policy, then review application logging against those definitions before tiering retention.
What's in the full article
Sawmills' full article covers the operational detail this post intentionally leaves for the source:
- Concrete collector placement guidance for DaemonSet, sidecar, and gateway patterns
- Example filtering logic for health checks, kube-probe traffic, and other low-value logs
- Practical routing and retention tiering approaches for different log classes
- How the vendor maps telemetry policy to day-to-day operational workflow
👉 Read Sawmills' analysis of Kubernetes log management at scale →
Kubernetes log volume and cost: where should teams stop it?
Explore further
19/08/2026 4:18 pm
Telemetry lifecycle control is now a governance discipline, not a tuning exercise. Kubernetes observability costs rise when teams treat logs as a by-product instead of a managed asset with explicit creation, retention, and discard rules. That shift matters because the same governance logic applies to identity events, service account activity, and secrets-related telemetry. Practitioners should treat log policy as a control surface, not a cleanup task.
A question worth separating out:
Q: Which control should teams prioritise first, collection or retention policy?
A: Retention policy should be defined first, because it forces teams to decide what each log class is for and where it belongs. Collection tools only execute policy, they do not create it. Once the retention model is clear, the collector architecture can support it instead of compensating for ambiguity.
👉 Read our full editorial: Kubernetes log volume grows faster than observability budgets
