Grafana's logs backend, in plain English, and the trade-off at its heart.
Loki is Grafana Labs' answer to log storage, and its pitch is a clever one: be like Prometheus, but for logs. That design choice is both its biggest strength and the thing to understand before you adopt it.
How the open-source observability stack fits together. Loki owns logs here.
What is Loki?
Loki is an open-source log aggregation system built to be cost-efficient at scale. Instead of indexing the full text of every log line, the traditional and expensive approach, it indexes only a small set of labels, like the service or environment, and stores the log content itself cheaply. You query it with LogQL, a language deliberately close to Prometheus's PromQL, and you read the results in Grafana. The current line is Loki 3.x.
The trade-off at its heart
The label-only index is why Loki is cheap to run, and also why broad, ad-hoc text searches across huge volumes can be slow: there is no full-text index to lean on. Grafana Labs has been closing that gap, rearchitecting Loki around Kafka for durability and acquiring Logline to speed up needle-in-a-haystack searches. Worth knowing which version you are on.
What it does well
Cheap at scale. The index-light design keeps storage and cost down where full-text systems balloon.
Native Grafana and Prometheus fit. Same labels, same mental model, one dashboard for logs and metrics side by side.
Simple operational story. Fewer moving parts than a full search cluster for the common case.
From the trenches
The thing that makes Loki cheap is the same thing people trip over. Because it indexes labels rather than the full text of every line, a broad question like "find this error message across every service" cannot lean on an inverted index; it scans the raw log chunks instead. Scoped by a label and a tight time range, that is fast. Unscoped across a large estate, practitioners report it running in minutes or hours where Elasticsearch answers in seconds.
The cost surprise follows from the same design. If your chunks live in cheap object storage with paid retrieval, a wide search can pull a lot of data back and the bill notices. And the operational story is not as small as the pitch suggests: a real Loki is several interconnected services with non-trivial configuration. None of this makes Loki the wrong choice, it makes it a choice with a shape. It is brilliant for label-scoped operational debugging and weak for open-ended forensic search. Teams that need the latter often keep a search-engine backend alongside, or look at lighter alternatives like VictoriaLogs.
The honest ledger
It is not a search engine. If your primary need is fast, arbitrary full-text search across everything, a system built for that may serve you better, though Loki is catching up.
Labels are a discipline, not a free lunch. High-cardinality labels hurt Loki just as they hurt Prometheus. Design them with care.
Best inside the Grafana world. You can use it standalone, but the value shows up next to Grafana and Prometheus.
So, is Loki for you?
If you want affordable logs that sit naturally alongside your metrics in Grafana, and your search patterns lean on labels rather than raw full-text, Loki is a strong, economical choice. If deep full-text search is your daily driver, weigh it against a purpose-built search system, and check where Loki's newer search features have landed.
What does your log bill look like, and is the spend buying you answers? Reply, or book a slot and tell me what you found.
|
Get the next one One signal a week. No noise. | |
|
If this was useful, Metrics & Mayhem sends one short, practical piece like it to IT operations leaders most weeks. No fluff, no vendor noise.
Prefer to start with the book? Read a free chapter. |
Sources / further reading
Grafana Loki project: grafana.com
Loki documentation: grafana.com/docs/loki
Loki vs Elasticsearch, the trade-offs (SigNoz): signoz.io
Why VictoriaLogs is pitched as a lighter alternative (ITNEXT): itnext.io