Montaste Prometheus y Grafana y ahora ves cuándo algo va mal: un pico de CPU, un servicio que deja de responder, una latencia que se dispara. Genial. Pero llega el momento de la verdad —el incidente real— y descubres el límite de las métricas: te dicen que el servicio falla, no por qué. El «por qué» está en los logs. Y ahí empieza el problema, porque los logs están repartidos: cada VM, cada contenedor, cada servicio guarda los suyos en su propia máquina. Investigar significa abrir cinco o diez sesiones SSH, hacer tail y grep en cada una, e intentar correlacionar a ojo lo que pasó a la vez en sitios distintos. A las tres de la mañana, con el servicio caído, eso es una tortura.
La solución es la otra mitad de la observabilidad: centralizar los logs en un sitio donde consultarlos todos juntos, correlacionados por tiempo, junto a las métricas que ya tienes. La herramienta que encaja mejor con un stack Prometheus + Grafana es Loki, del mismo ecosistema. Este artículo explica qué es, por qué es más ligero (y barato) que la pila ELK de siempre, y cómo montarlo sobre tu cloud privado con Proxmox.
Conviene tener claro por qué necesitas ambos, porque no compiten, se completan:
El flujo de una investigación bien equipada es este: la métrica te alerta («latencia disparada a las 14:32»), y el log te explica («a las 14:32, la base de datos rechazaba conexiones por límite de conexiones alcanzado»). Sin logs centralizados, ese segundo paso es entrar por SSH a buscar. Con ellos, es una consulta.
Durante años, «centralizar logs» significaba montar la pila ELK (Elasticsearch, Logstash, Kibana). Funciona, es potente, y tiene un problema conocido: es cara en recursos. Elasticsearch indexa el contenido completo de cada log para poder buscar cualquier palabra, y ese índice consume muchísima RAM, CPU y disco. Para un cloud privado de tamaño medio, montar y mantener ELK es a menudo desproporcionado.
Loki (de Grafana Labs) nace de una idea distinta y más económica: no indexar el contenido de los logs, solo unas pocas etiquetas. En lugar de indexar cada palabra de cada línea, Loki indexa metadatos —de qué máquina viene, qué servicio, qué nivel— y guarda el texto del log comprimido, sin indexar. Cuando buscas, filtra rápido por etiquetas hasta el conjunto relevante y luego escanea ese texto. El resultado: muchísimo menos almacenamiento y recursos que ELK, a cambio de un modelo de búsqueda algo distinto (filtras por etiquetas y luego por contenido, no búsqueda libre indexada de todo).
Para la mayoría de casos de un cloud privado, ese compromiso es exactamente el correcto: quieres ver «los logs de este servicio en esta ventana de tiempo», que es justo lo que Loki hace barato. Y encaja de forma nativa con Grafana, que probablemente ya tienes.
El stack de logs con Loki tiene tres componentes, paralelos a los de métricas:
| Pieza | Qué hace | Equivalente en métricas |
|---|---|---|
| Agente (Promtail / Grafana Alloy) | Recoge los logs de cada máquina y los envía a Loki | node_exporter |
| Loki | Recibe, comprime y almacena los logs; los sirve a consultas | Prometheus |
| Grafana | Consulta y visualiza los logs (lenguaje LogQL) | Grafana (el mismo) |
El agente se instala en cada máquina que quieras vigilar (o se recoge de forma centralizada) y va enviando sus logs a Loki con etiquetas que identifican origen y tipo. Loki los almacena de forma eficiente. Y Grafana —la misma instancia donde ya ves las métricas— los consulta con LogQL, un lenguaje parecido al de Prometheus pero para logs: filtras por etiquetas y luego por contenido.
# Ejemplo conceptual de consulta LogQL en Grafana
# Logs del servicio "nginx" en el nodo "web-01" que contienen "error 500"
{job="nginx", host="web-01"} |= "error 500"Igual que con las métricas, conviene que el stack de logs viva fuera del clúster que vigila: si el clúster cae, quieres poder leer sus últimos logs desde un sitio que siga en pie.
Aquí está el motivo por el que Loki gana para quien ya usa Prometheus: métricas y logs en la misma pantalla, correlacionados. En Grafana ves la gráfica de latencia con su pico a las 14:32, y con un clic saltas a los logs de ese mismo instante y de ese mismo servicio, sin cambiar de herramienta, sin abrir SSH, sin correlacionar a mano. El pico y su explicación, uno al lado del otro.
Eso convierte la investigación de un incidente de una arqueología por diez servidores en un flujo natural: veo la anomalía en la métrica → salto al log del momento → encuentro la causa. Es la diferencia entre depurar con contexto y depurar a ciegas. Y para un equipo pequeño que no puede permitirse una persona dedicada a bucear en logs, ese ahorro de tiempo por incidente es enorme.
Con eso cierras la observabilidad: sabes que algo falla por las métricas, y por qué por los logs, todo desde un mismo Grafana.
¿Para qué necesito logs centralizados si ya tengo métricas? Porque resuelven cosas distintas. Las métricas detectan y alertan de que algo va mal, pero no explican el detalle. Los logs contienen el mensaje de error exacto, la traza, la causa. Sin centralizar, investigar significa entrar por SSH en varias máquinas y correlacionar a mano. Centralizados, es una consulta con contexto.
¿Loki o la pila ELK (Elasticsearch)? ELK es potente pero caro en recursos, porque indexa el contenido completo de cada log. Loki indexa solo etiquetas y guarda el texto comprimido, así que consume mucho menos almacenamiento y RAM, a cambio de un modelo de búsqueda por etiquetas más que por texto libre. Para un cloud privado de tamaño medio, Loki suele ser el compromiso correcto, sobre todo si ya usas Grafana.
¿Qué es Promtail o Grafana Alloy?
Son los agentes que recogen los logs de cada máquina y los envían a Loki, etiquetándolos por origen. Son el equivalente del node_exporter en el mundo de las métricas. Alloy es la evolución más reciente y unificada; Promtail, el agente clásico de Loki. Cualquiera de los dos hace el trabajo.
¿Puedo ver métricas y logs juntos? Sí, y es la gran ventaja de Loki: se consulta desde la misma Grafana donde ya ves las métricas de Prometheus. Puedes ver el pico en una gráfica y saltar a los logs de ese instante con un clic, correlacionados por tiempo, sin cambiar de herramienta ni abrir SSH.
¿Cuánto tiempo debo guardar los logs? Depende de para qué los necesites: investigar incidentes recientes pide días o semanas; ciertos requisitos de cumplimiento pueden exigir más. Como los logs pesan, se define una retención por antigüedad que equilibre utilidad y coste de almacenamiento. Loki permite configurar cuánto tiempo se conservan.
¿Ves cuándo algo falla pero pierdes horas buscando por qué entre logs repartidos por medio parque? Montamos contigo la observabilidad completa sobre Proxmox —métricas y logs en un mismo Grafana— para que investigar un incidente sea una consulta, no una expedición. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
Asignar a tus VMs más CPU y RAM de la que el servidor tiene físicamente —overcommit— es lo que permite meter más máquinas en el mismo hardware. Con la CPU suele salir bien; con la memoria, hecho a la ligera, es la receta de un servidor que muere de golpe. Explicamos por qué la CPU se sobreasigna con tranquilidad y la RAM con mucho cuidado, y las herramientas (ballooning, KSM) para hacerlo con cabeza.
Ceder unas horas de una GPU suele significar crear un usuario, repartir claves SSH, revisar permisos y acordarse de retirarlo todo después. RunSnack reduce eso a ejecutar un script y pasar un enlace que abre una terminal en el navegador, dentro de un contenedor Docker con acceso a la GPU del anfitrión. Es una idea buena y pequeña, con una frontera de seguridad que su propio autor documenta sin adornos: repasamos qué resuelve, qué no, y cuándo la respuesta correcta sigue siendo una máquina virtual.
Proxmox VE deja crear snapshots desde cualquier sitio, pero no hay una vista de todos los del clúster. ProxSnap, escrito en Rust por el autor de ProxLB, lista, filtra por fecha y borra snapshots viejos desde la API. Qué hace de verdad, qué cuesta un snapshot olvidado según el almacenamiento, y cómo montar una política sin llevarte por delante algo que hacía falta.