// the find
grafana/loki
Like Prometheus, but for logs.
Loki is a log aggregation system that indexes only metadata labels rather than full log content, making it significantly cheaper to run than Elasticsearch-based stacks. It's the log component of Grafana's observability stack, pairing with Prometheus metrics and Grafana dashboards. Best fit for Kubernetes environments where you're already using Prometheus.
- Label-based indexing model means storage costs are a fraction of Elasticsearch/OpenSearch — you store compressed log chunks and only index the stream labels, which is a genuinely different architectural tradeoff worth making
- Ships as a single binary that can run as a monolith or split into microservices with the same config, so you can start simple and scale out without rewriting your setup
- LogQL query language is purposefully Prometheus-inspired, so teams already writing PromQL have a short learning curve, and metric queries over logs (rate, count_over_time) work the way you'd expect
- Loki Canary is a built-in end-to-end monitoring tool that actually validates log delivery and measures loss — most competing systems don't ship this
- The label cardinality constraint bites hard in practice — high-cardinality labels like user IDs or request IDs blow up the index and degrade performance badly; teams coming from Elasticsearch keep hitting this wall
- Full-text search is slow by design: grep-style log queries scan raw chunks rather than an inverted index, so ad-hoc searches over large time ranges on busy clusters are noticeably slower than Elasticsearch
- Helm chart is being spun out to a separate community repo, which adds adoption risk — anyone running Loki via Helm now has to track a migration and a new maintenance home with unclear long-term ownership
- Upgrade path has historically been painful; the CHANGELOG is full of breaking schema changes and compactor behavior changes that require careful sequencing, and the 'upgrading' docs are lengthy for good reason