Skip to content

SYSTEM Cited by 2 sources

Loki

Loki (grafana.com/docs/loki) is Grafana Labs' open-source, horizontally scalable, highly available log aggregation system. It is deliberately designed as the Prometheus-analogue for logs: the same label-based data model, the same operational shape, but for log lines rather than time-series metrics.

Core design

The architectural thesis is to keep log management cost-efficient and easy to operate at scale by refusing to index log content. Only labels — service, cluster, environment, region, and similar low-cardinality dimensions — are indexed. The log content itself is written to object-storage-backed chunks (S3, GCS, Azure Blob). Queries filter by labels to pick the right chunks, then scan those chunks linearly.

This design choice defines Loki's price/performance envelope:

  • Storage cost is low — no inverted full-text index to maintain.
  • Operational cost is low — the index is small enough to be cheap to run, back up, and scale.
  • Label-scoped queries are fast — narrow time + label + text range scans over a bounded set of chunks.
  • High-cardinality lookups are slow — a query for a single UUID or request ID can only be satisfied by scanning whole chunks, since the UUID is not a label. (Source: sources/2026-04-22-grafana-grafana-labs-acquires-logline)

This is the architectural opposite of Elasticsearch's full-text-indexed approach, and is why Loki has substantially lower storage costs than log systems that index content.

The high-cardinality gap

Loki's own cost-efficiency thesis is also its structural limitation. The labels that are cheap to index are low-cardinality by design; the attributes operators actually want to search by during an incident — request ID, trace ID, user ID, job ID, UUID — are high-cardinality by nature. No pure label-index scheme can close that gap.

In 2026-04, Grafana Labs acquired Logline (Jason Nochlin) specifically to layer a secondary, high-cardinality-over-object- storage index under Loki's existing label scheme — without replacing the label index or regressing Loki's storage-cost floor. Early benchmark reported at GrafanaCON 2026: a UUID lookup that previously scanned 3.5 TB of data (returning no match) now scans 8 GB — a 99.7 % reduction in data scanned. See needle-in-haystack log query for the query-class framing. (Source: sources/2026-04-22-grafana-grafana-labs-acquires-logline)

Relationship to Grafana Cloud Logs

Grafana Cloud Logs is the Grafana Labs-operated, managed Loki offering. Features typically launch in Grafana Cloud Logs first under managed control before landing in Loki OSS.

Cortex lineage and rearchitecture trajectory

Loki started from the same Cortex architectural foundation that Mimir and Pyroscope 1.x did. Per the Pyroscope 2.0 launch post: "the same foundation that the Mimir and Loki projects started with." Mimir has since rearchitected along the Cortex-to-object-store pattern, and Pyroscope 2.0 has followed. Loki has been on a similar convergence — many features land in Grafana Cloud Logs first, including the object-store-first design moves. (Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)

Seen in

  • sources/2026-04-22-grafana-grafana-labs-acquires-logline — the canonical wiki articulation of Loki's label-based indexing thesis and its high-cardinality blind spot. Also introduces Logline as the planned secondary index to close that gap. Rollout: Grafana Cloud Logs limited private preview 2026-04-22; Loki OSS targeted for the next major release "in the coming year."
  • sources/2026-04-22-grafana-introducing-pyroscope-2-0 — references Loki alongside Mimir and Pyroscope as the three Cortex-derived observability databases converging on the same object-store-first rearchitecture.
Last updated · 517 distilled / 1,221 read