Loki: Log Aggregation That Skips Full-Text Indexing

The Problem: Log Storage That Costs Too Much or Searches Too Much

Most log aggregation systems index every word in every log line. That makes search fast but storage and operation expensive. Loki takes the opposite path. It stores compressed, unstructured logs and indexes only a set of labels for each log stream. The README is explicit: Loki does not do full text indexing on logs. This design makes it cheaper to run and simpler to operate, but it also sets a hard boundary on what you can query. The intended user is someone already running Prometheus and Kubernetes. Loki reuses the same label model as Prometheus, so you can switch between metrics and logs using the same labels. If you are not already invested in Prometheus labels, Loki's core value proposition weakens.

Push, Not Pull: How Loki Differs from Prometheus

Loki is inspired by Prometheus but diverges in a key mechanism. Prometheus pulls metrics from targets. Loki receives logs via push. The README states this directly: Loki delivers logs via push, instead of pull. That means an agent, Grafana Alloy, is responsible for gathering logs and sending them to Loki. Promtail is now feature complete and future development has moved to Alloy. This push model fits Kubernetes well because Pod labels can be scraped and indexed automatically. The architecture has three components: Alloy for collection, Loki for storage and query processing, and Grafana for querying and display.

Getting Loki Running: Components and Commands

The README points to the installation and getting started guides at grafana.com/docs/loki/latest. It does not include a quick start command in the README itself, but the structure is clear. You install Loki, install Alloy, and then configure Grafana to use Loki as a datasource, which requires Grafana v6.0 or later. The documentation sections list the API for getting logs in, the labels guide, and the operations guide. The Docker Driver Client is a Docker plugin that sends logs directly to Loki from Docker containers. LogCLI provides a command-line interface for querying logs. Loki Canary monitors an installation for missing logs. The Getting started section links out to the official docs for installation. Expect to configure Alloy to scrape your log sources and push them to Loki's API endpoint.

The Helm Chart Fork: A Concrete Operational Risk

Effective March 16, 2026, the Grafana Loki Helm chart is forked to a new repository, grafana-community/helm-charts. The chart in the Loki repository will continue to be maintained for GEL users only. GEL likely refers to Grafana Enterprise Logs, though the README does not expand the acronym. This is a significant operational detail. If you use the Helm chart to deploy Loki, your upgrade path changes. The community chart moves to a different repository, and the main repo chart may diverge. This is not a hypothetical concern. The README flags it with a warning and points to issue #20705 for details. Before adopting Loki, check that issue and decide whether you are comfortable with the community fork's maintenance cadence. This is exactly the kind of thing that bites teams six months into a deployment.

What You Cannot Do: The Full-Text Search Limitation

The biggest limitation is also the design's core. Loki does not index log contents, only labels. That means you cannot run a query like "find every line containing the string 'connection refused' across all services." You must first narrow down by labels, such as service name and pod, then filter the content. The README does not describe the query language in detail, but the absence of full-text indexing is clear. For incident investigations where you know the service and time range, this is fine. For exploratory search across an entire cluster, it is the wrong tool. The label-based approach works only if you have already assigned meaningful labels at ingestion. If you collect logs without labels, you have effectively built a black hole.

Alternatives: Elasticsearch and the Full-Text Approach

The natural alternative is Elasticsearch, which does full-text indexing on log contents. The difference is fundamental. Elasticsearch lets you search any substring across all logs, but it requires more storage and more operational effort. Loki deliberately sacrifices that capability to reduce cost and complexity. The README positions Loki against other log aggregation systems by emphasizing that it does not do full-text indexing. If your team already runs Elasticsearch and has the operational capacity, switching to Loki means giving up search features you may rely on. If you are starting fresh and your queries are label-driven, Loki's approach is simpler. There is no middle ground in the README. You must choose between indexing content or indexing only metadata.

Licence and Maintenance Costs

Loki is licensed under AGPL-3.0. That is a strong copyleft licence. If you modify Loki and distribute it as a service, you may need to release your modifications. For internal use, this is usually not a problem. For vendors who embed Loki, it is a serious consideration. Maintenance cost is visible in the release cadence. The repository shows v3.7.9 and v3.6.19 as recent releases, both published on 2026-10-20. The last push was on 2026-11-02, which suggests active development. The README also notes that Promtail is feature complete, so you will not get new features there. Upgrades require reading the dedicated upgrading guide. The Helm chart fork adds another maintenance surface. Budget time for tracking both the main project and the chart repository.

Editorial conclusion

Adopt Loki if you run Kubernetes and want a log system that shares labels with Prometheus, and if you can live without full-text search. Do not adopt it if your workflows depend on searching raw log text or if you need a single tool for both logs and metrics. Before committing, verify your retention and cardinality requirements against Loki's label model, and test the Helm chart migration path to grafana-community/helm-charts if you rely on the current chart.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes