The Grafana Stack: Loki, Tempo, and Mimir for Open Observability
Actualizado: 2026-05-03
Grafana Labs has built a complete observability stack that rivals classic options (Elasticsearch + Jaeger + Prometheus) and cloud offerings (Datadog, New Relic). Three open components: Loki[1] for logs, Tempo[2] for traces, Mimir[3] for metrics. All with similar design: object-storage-backed, minimal indices, queries via Grafana.
Key takeaways
- The shared pattern of all three projects is storing data in S3/GCS/Azure Blob with only a minimal index: ~20x cheaper than SSD with Elasticsearch indices.
- Loki doesn’t index log content, only labels — slow for free-text searches, but very economical at high volume.
- Tempo stores traces without indexing them (only traceID); fits the “metrics/logs to detect, traces to diagnose” pattern.
- Mimir is horizontal Prometheus: same PromQL, but clusterable to billions of series.
- Cross-correlation between the three signals — from metric to log to trace with a click — is the true differentiating value of the unified stack.
The common pattern: object storage + minimal index
The shared innovation of all three projects is storing data in S3/GCS/Azure Blob buckets with only a minimal index for lookup. This contrasts with:
- Elasticsearch: indexes all content, expensive in CPU and disk.
- Jaeger with Cassandra: requires heavy cluster.
- Prometheus TSDB: scales vertically, doesn’t share data across instances easily.
S3 storage costs ~20x less than SSD with Elasticsearch indices. For low-query-rate data (old logs, historical traces), the economics are dramatic.
Loki for logs
Loki[1] doesn’t index log content, only labels like {app="api", level="error"}. Searches inside logs happen by scanning — slower than Elasticsearch, but much cheaper.
Where Loki wins:
- High volume (TB/day) with occasional access.
- Teams already using Prometheus (same label model).
- Budgets where Elasticsearch doesn’t fit.
Where it doesn’t:
- Very frequent free-text searches (Elasticsearch still wins).
- Complex analytics over log content.
Tempo for traces
Tempo[2] stores traces without indexing them (only the traceID). To search by attribute (e.g., “all traces for /api/v1/orders”), you need a secondary index in Prometheus/Loki.
This may sound limiting, but it fits a common pattern: use metrics/logs to detect problems, use traces to diagnose. From a Grafana dashboard, one click takes you from an anomalous metric to the correlated trace.
Versus Jaeger: Tempo is cheaper to operate (no Cassandra), but Jaeger has a richer UI and more flexible searches.
Mimir for metrics
Mimir[3] is horizontal Prometheus: same PromQL, same data, but clusterable to billions of series. Uses the same object-storage + index pattern.
For a single Prometheus, it adds nothing. For multi-tenancy, high cardinality, or long retention (>1 year), Mimir is Grafana-Cloud-scale.
Similar alternatives:
- Thanos[4]: slightly different patterns, same goal.
- Cortex[5]: Mimir is Grafana Labs’ fork/refactor of Cortex.
- VictoriaMetrics[6]: stands out for resource efficiency.
Integration with the rest of the stack
The real value of the Grafana stack is cross-correlation:
- From a panel with an anomalous metric, click → related logs in Loki.
- From a log with an error, click → trace in Tempo.
- From a trace, click → metrics of the involved service.
Grafana Labs calls this “correlations” and it works well when the three signals share common labels (namespace, service, pod). With OpenTelemetry as unified SDK, this correlation is automatic.
Also see Cilium with Hubble for the network layer — Hubble and Grafana complement each other covering different stack levels. For broader Kubernetes context, Pixie for K8s observability fills the reactive diagnosis zone the Grafana stack doesn’t cover natively.
When to choose the Grafana stack
Clear scenarios:
- Team already uses Grafana + Prometheus. Adding Loki and Tempo is natural evolution.
- Limited budget with medium-high volumes. Open-source stack + object storage is significantly cheaper than cloud solutions.
- Simple multi-tenancy. All three components support native tenant isolation.
Where to choose something else:
- Complex log analytics. Elasticsearch/Splunk still hold an edge.
- Datadog ecosystem productivity integration. If your team already lives in Datadog, switching just for open-source rarely pays off.
- No operational experience with object storage. Efficiency comes from knowing how to tune S3/GCS lifecycle policies, sampling, and retention.
Conclusion
The Grafana stack (Loki + Tempo + Mimir) offers open-source observability with favourable economics at scale, thanks to the common pattern of object storage + minimal index. For cost-sensitive teams or those valuing full stack control, it’s a legitimate alternative to the Elasticsearch + Jaeger duo and to proprietary cloud solutions.
