Why Loki Beats ELK for Kubernetes Logging: Architecture and Cost Benefits

Background and Motivation

When designing a log solution for a container cloud, we found ELK/EFK heavy and many Elasticsearch search features unnecessary, so we chose Grafana's open‑source Loki. Loki aims to minimize the cost of switching between metrics and logs, improving incident response time and user experience.

ELK Problems

Full‑text indexing solutions like ELK provide rich features but are complex, resource‑hungry, and often include unnecessary functionality; most queries only need time ranges and simple parameters, making ELK overkill.

Cost

Inverted‑index based full‑text search incurs high storage and processing costs. Alternative designs such as OKlog reduce cost and simplify operation but sacrifice query convenience. Loki’s third goal is to offer a more cost‑effective solution.

Overall Architecture

Loki’s architecture mirrors Prometheus, using the same label‑based indexing. Promtail runs as a DaemonSet on each node, collects logs, adds metadata via the Kubernetes API, and forwards them to Loki.

Log storage consists of a Distributor and Ingester. The Distributor receives logs, hashes them to determine the target Ingester, and replicates data (default three times) for redundancy.

Ingester builds compressed chunks (gzip) and flushes them to storage when size or time thresholds are met, then starts a new chunk.

Querier handles read requests by selecting time ranges and label selectors, consulting the index, and grepping matching logs, also fetching unflushed data from Ingesters.

Scalability

Index storage can be Cassandra, Bigtable, or DynamoDB, while chunks reside in object storage. Distributor and Querier are stateless; Ingester is stateful but rebalances chunks when nodes are added or removed, ensuring elasticity.