Entre El Rack, Predify, y el resto de servicios repartidos en el VPS y el homelab, cuando algo falla mi flujo hasta ahora era entrar por SSH y revisar journalctl o docker logs servicio por servicio —funcional, pero lento, y sin ninguna vista centralizada de qué pasó en todos los servicios a la vez en un momento concreto—. Ya tenía Prometheus y Grafana corriendo para métricas; Loki era la pieza que faltaba para tener también los logs en el mismo sitio.
La decisión de diseño que lo hace ligero
A diferencia de Elasticsearch, que indexa el contenido completo de cada log, Loki solo indexa las etiquetas (qué servicio, qué máquina, qué nivel de severidad) — el contenido del log en sí se comprime y almacena sin indexar línea por línea. Esto hace que el almacenamiento sea entre 5 y 10 veces más ligero que un stack ELK equivalente para el mismo volumen de logs, a cambio de una búsqueda de texto completo algo menos potente si no sabes de antemano qué servicio estás investigando.
Loki asume que ya sabes qué servicio estás depurando, y solo te hace buscar dentro de eso — Elasticsearch asume que no lo sabes y lo indexa todo, pagando ese precio en almacenamiento constantemente.
El día a día
Promtail corre en cada máquina, recoge journald, logs de contenedores Docker/Podman y ficheros de log personalizados, y los envía a Loki etiquetados. Desde Grafana, correlacionar un pico de CPU a las 3 de la madrugada (que ya veía en Prometheus) con los logs de error exactos que lo causaron es cuestión de un clic en el mismo panel, sin cambiar de herramienta ni de interfaz.
Dónde cojea
La búsqueda dentro de un stream etiquetado es rápida, pero si necesitas buscar un término concreto sin saber de antemano en qué servicio está, la experiencia es más lenta que un buscador de texto completo tradicional — en la práctica esto encaja con cómo depuras de verdad (casi siempre sabes qué servicio estás investigando), pero es una limitación real del diseño, no un detalle menor.
