On-node logs are bounded on purpose: each stream rotates at a fixed cap, deleting old entries as new ones arrive, so a busy node cannot fill its own /var. Those caps tell you how much history the node holds before it rotates away, which is your deadline for shipping logs off-node, and they are the starting point for sizing your own store.

The on-node caps

These are hot buffers, not archives. On a busy node the API audit log can reach its cap in well under 90 days, so do not treat "90 days" as a retention guarantee; treat the off-node store as the real retention.

Estimate ingest per node

To size your store, estimate what one node produces per day, then multiply by node count and add headroom for incident-time spikes:

• Container logs dominate, and vary entirely with your workloads. Measure a representative node rather than guessing.
• journald is steady and modest once you filter to the units you keep.
• Audit is bounded by the caps above; the API audit stream is the largest of the three on a busy control plane.

A spike matters more than the average: during an incident, error logging can jump several-fold, so size ingesters and buffers for the peak, not the mean.

Retention tiers in your store

Keep tiers rather than one flat retention, the same idea as metrics:

• Hot, queryable logs for days to weeks, for live troubleshooting.
• Compacted, cheap logs for the long window compliance requires, on object storage. Loki's compactor merges and applies retention per tier.

Cost versus compliance

The two pulls are opposite: cost wants short retention and aggressive filtering, compliance wants the audit trail kept for a year or more. Resolve it by treating the two kinds of logs differently. Keep operational logs (container, journald) hot for a short window and drop the noisy ones, and keep the three audit streams for the full compliance window in cheap, write-once object storage. That way you pay for long retention only on the small, high-value streams, not on everything. See Ship audit logs off-node .