Grafana Loki
02 / 02

Ingestion, Storage & When Loki Fits

Ingestion, Storage & When Loki Fits

Promtail & Object Storage

Promtail (or the newer Grafana Alloy) is the client-side agent that discovers log sources, attaches labels, and pushes data to Loki's ingestion API — analogous to how node exporters feed Prometheus. Loki stores the actual compressed log chunks in cheap, durable object storage (S3, GCS, Azure Blob) rather than a specialized proprietary engine, keeping operational cost low.

Scaling & Retention

Loki's microservices-style architecture separates components (distributor, ingester, querier) with distinct responsibilities, letting write- and read-heavy workloads scale independently. Retention/compaction policies control how long chunks are kept, balancing historical-debugging needs against ongoing storage cost.

The Query Tradeoff

Minimal indexing is a genuine tradeoff: a query needing to search arbitrary text across a huge volume without narrowing by label first may need to scan more raw data at query time, since Loki has no full-text index to jump directly to matches the way Elasticsearch can. Narrowing by labels before filtering content is the standard way to keep queries fast.

Why Teams Choose It — and When Not To

Teams already on Prometheus/Grafana often pick Loki because its label philosophy and native dashboard integration let logs, metrics, and traces be correlated in one tool with a consistent mental model — reducing the integration friction of stitching together unrelated products. A team whose primary need is complex, ad hoc full-text search across huge volumes without well-defined label dimensions may find Elasticsearch's full-text indexing better suited, despite its higher operational cost.

Keep your own version of these notes — editable, searchable, and organised by your stack.

Start free