El stack Grafana: Loki, Tempo y Mimir para observabilidad abierta
Actualizado: 2026-05-03
Grafana Labs ha construido un stack completo de observabilidad que rivaliza con opciones clásicas (Elasticsearch + Jaeger + Prometheus) y cloud (Datadog, New Relic). Tres componentes abiertos: Loki[1] para logs, Tempo[2] para trazas, Mimir[3] para métricas. Todos con diseño similar: almacenamiento en object storage, índices mínimos, consulta vía Grafana.
Puntos clave
- El patrón compartido de los tres proyectos es almacenar datos en S3/GCS/Azure Blob con solo un índice mínimo: ~20x más barato que disco SSD con índices Elasticsearch.
- Loki no indexa contenido de logs, solo etiquetas — lento en búsquedas de texto libre, pero muy económico a alto volumen.
- Tempo almacena trazas sin indexarlas (solo traceID); encaja con el patrón “métricas/logs para detectar, trazas para diagnosticar”.
- Mimir es Prometheus horizontal: mismo PromQL, pero clusterizable a miles de millones de series.
- La correlación cruzada entre las tres señales — de métrica a log a traza con un click — es el verdadero valor diferencial del stack unido.
El patrón común: object storage + índice mínimo
La innovación compartida de los tres proyectos es almacenar datos en buckets S3/GCS/Azure Blob con solo un índice mínimo para localizar. Esto contrasta con:
- Elasticsearch: indexa todo el contenido, caro en CPU y disco.
- Jaeger con Cassandra: requiere clúster pesado.
- Prometheus TSDB: escala verticalmente, no comparte datos entre instancias fácilmente.
El coste de almacenamiento en S3 es ~20x más barato que disco SSD con índices Elasticsearch. Para datos con baja tasa de consulta (logs antiguos, trazas históricas), la economía es dramática.
Loki para logs
Loki[1] no indexa el contenido de los logs, solo etiquetas como {app="api", level="error"}. Las búsquedas dentro del log se hacen por escaneo — más lento que Elasticsearch, pero mucho más barato.
Casos donde Loki gana:
- Alto volumen (TB/día) con acceso ocasional.
- Equipos que ya usan Prometheus (mismo modelo de labels).
- Presupuestos donde Elasticsearch no cuadra.
Casos donde no:
- Búsquedas de texto libre muy frecuentes (Elasticsearch sigue ganando).
- Analítica compleja sobre contenido de log.
Tempo para trazas
Tempo[2] almacena trazas sin indexarlas (solo el traceID). Para buscar por atributo (p. ej., “todas las trazas del endpoint /api/v1/orders”), se necesita un índice secundario en Prometheus/Loki.
Esto puede parecer limitante, pero encaja con un patrón común: usar métricas/logs para detectar problemas, usar trazas para diagnosticar. Desde un dashboard de Grafana, un click lleva de una métrica anómala a la traza correlacionada.
Comparado con Jaeger: Tempo es más barato de operar (sin Cassandra), pero Jaeger tiene UI más rica y búsquedas más flexibles.
Mimir para métricas
Mimir[3] es Prometheus horizontal: mismo PromQL, mismos datos, pero clusterizable hasta miles de millones de series. Usa el mismo patrón de object storage + índice.
Para un único Prometheus, no aporta. Para multi-tenancy, alta cardinalidad o retención larga (>1 año), Mimir es la opción a escala de Grafana Cloud.
Alternativas similares:
- Thanos[4]: patrones ligeramente diferentes, mismo objetivo.
- Cortex[5]: Mimir es un fork/refactor de Cortex hecho por Grafana Labs.
- VictoriaMetrics[6]: destaca por eficiencia de recursos.
Integración con el resto del stack
El valor real del stack Grafana está en la correlación cruzada:
- Desde un panel con métrica anómala, click → logs relacionados en Loki.
- Desde un log con error, click → traza en Tempo.
- Desde una traza, click → métricas del servicio involucrado.
Grafana Labs llama a esto “correlations” y funciona bien cuando las tres señales comparten etiquetas comunes (namespace, service, pod). Con OpenTelemetry como SDK unificado, esta correlación es automática.
Ver también Cilium con Hubble para la capa de red — Hubble y Grafana se complementan cubriendo distinto nivel del stack. Para contexto de Kubernetes más amplio, Pixie para observabilidad K8s llena la zona de diagnóstico reactivo que Grafana stack no cubre de forma nativa.
Cuándo elegir el stack Grafana
Escenarios claros:
- Equipo ya usa Grafana + Prometheus. Añadir Loki y Tempo es evolución natural.
- Presupuesto limitado con volúmenes medios-altos. El stack open-source + object storage es significativamente más barato que soluciones cloud.
- Multi-tenancy simple. Los tres componentes soportan aislamiento de tenant de forma nativa.
Dónde elegir otra cosa:
- Analítica compleja sobre logs. Elasticsearch/Splunk siguen teniendo ventaja.
- Integración con el ecosistema de productividad de Datadog. Si el equipo ya vive en Datadog, cambiar solo por open-source rara vez compensa.
- Sin experiencia operativa con object storage. La eficiencia viene de saber afinar las lifecycle policies de S3/GCS, el sampling y la retención.
Conclusión
El stack Grafana (Loki + Tempo + Mimir) ofrece observabilidad open-source con economía favorable a gran escala, gracias al patrón común de object storage + índice mínimo. Para equipos sensibles al coste o que valoran el control completo sobre el stack, es una alternativa legítima al dúo Elasticsearch + Jaeger y a las soluciones cloud propietarias.
