Why Loki Beats ELK for Cloud‑Native Log Management: Architecture and Benefits

When designing a logging solution for a container cloud, the author found mainstream ELK/EFK stacks too heavyweight and, given that many complex search features were unnecessary, chose Grafana's open‑source Loki system.

Background and Motivation

In a container cloud, when an application or node encounters an issue, metrics and alerts from Prometheus indicate the problem, but they lack the necessary log context. Pods output logs to stdout/stderr, and without a log system administrators must manually retrieve logs via the UI or command line, which becomes impossible if the application crashes. Switching between Kibana and Grafana for metrics and logs also degrades user experience. Loki aims to minimize the cost of switching between metrics and logs, reducing incident response time and improving user experience.

Problems with ELK

Traditional log collection solutions like ELK index logs for full‑text search, offering rich functionality but at the cost of high resource consumption and operational complexity. Most queries only need a time range and simple parameters (e.g., host, service), making ELK an overkill.

Cost Considerations

Full‑text search solutions incur high costs due to inverted‑index creation and sharing. Alternative designs such as OKlog provide lower cost and simpler operation but sacrifice query convenience. Loki seeks a cost‑effective solution without compromising usability.

Overall Architecture

Loki uses the same label‑based indexing as Prometheus, allowing queries on logs and metrics with the same selectors, greatly reducing storage for log indexes. Promtail runs as a DaemonSet on each node, collects logs, adds metadata via Kubernetes API, and forwards them to Loki.

The storage architecture stores chunks in object storage and indexes in systems like Cassandra, Bigtable, or DynamoDB. Distributor and Querier are stateless; Ingester is stateful but rebalances chunks when nodes are added or removed.

Write Path

Log data is written via the Distributor and Ingester components.

Distributor

Promtail sends logs to the Distributor, the first component that receives them. To avoid overwhelming the database, the Distributor batches and compresses logs (gzip) before passing them to Ingester.

Ingester

Ingester builds compressed chunks from incoming logs. When a chunk reaches a size or time threshold, it flushes the chunk to storage and starts a new empty chunk. Redundancy is achieved by replicating each chunk (default replication factor is 3).

Read Path

Querier

Querier handles read requests by taking a time range and label selector, consulting the index to find matching chunks, and performing distributed greps to return results. It also retrieves the latest unflushed data from Ingester, enabling parallel query execution for large workloads.

Scalability

Loki’s index storage can use Cassandra, Bigtable, or DynamoDB, while chunks reside in various object stores. Distributor and Querier are stateless; Ingester, though stateful, rebalances chunks across the ring when nodes are added or removed. The underlying storage implementation, Cortex, has been proven in production for years.

With this understanding, the author feels confident to experiment with Loki in their environment.