Hay una pregunta que separa a los equipos que operan infraestructura con confianza de los que viven apagando incendios: ¿cuánta memoria y CPU deberían tener tus pods?
Si la respuesta de tu equipo es “los pusimos en 512Mi y 500m porque era el default” o “los subimos hasta que dejó de crashear”, no estás solo. El resultado es siempre el mismo: pods que consumen el doble de lo que necesitan e inflan tu factura, o pods que se quedan cortos y mueren con OOMKilled a las 3 AM.
La solución existe y es open source: Grafana + Loki + Prometheus. El problema, como siempre, no es la tecnología — es todo lo que implica tenerla corriendo de forma útil y mantenible.
¿Por qué necesitás observabilidad en Kubernetes?
Kubernetes es una caja negra por diseño. Abstrae la infraestructura para que los desarrolladores no tengan que pensar en servidores. Pero esa abstracción tiene un costo: sin herramientas de observabilidad, no tenés idea de qué está pasando adentro.
Sin observabilidad, estas preguntas no tienen respuesta:
- ¿Cuánta memoria está usando realmente mi aplicación versus lo que le asigné?
- ¿Mis pods están siendo CPU-throttled sin que nadie lo note?
- ¿Por qué el servicio de pagos empezó a responder lento hace 20 minutos?
- ¿Qué pod generó ese error que reportó el cliente?
- ¿Estoy pagando por nodos que están al 20% de utilización?
¿Mis requests y limits de CPU/memoria están bien configurados, o estoy tirando plata o generando inestabilidad? Sin métricas históricas, esta pregunta no tiene respuesta posible.
El problema invisible: tus logs desaparecen
Antes de hablar de dashboards, hay un problema más fundamental que muchos equipos descubren de la peor manera: en Kubernetes, los logs son efímeros.
Cuando un pod se reinicia, se escala, se mueve a otro nodo o simplemente muere — y en Kubernetes esto pasa todo el tiempo — sus logs desaparecen con él. No hay disco persistente que los guarde. Se fueron.
Si tu aplicación tuvo un error a las 2 AM y el pod se recicló automáticamente, cuando tu equipo llega a las 9 AM a investigar, no hay nada que mirar. El pod que falló ya no existe, fue reemplazado por uno nuevo y sano que no tiene idea de lo que pasó antes.
El problema se multiplica con Spot Instances (que se interrumpen sin aviso) y Karpenter con consolidación activa (que mueve pods entre nodos constantemente). Cuanto más dinámica es tu infraestructura, más frecuentemente desaparecen tus logs.
Las opciones para persistir logs (y sus costos)
La industria tiene soluciones, pero la mayoría viene con una factura considerable:
O pagan de más por logs, o directamente no los persisten y esperan que los problemas no ocurran fuera del horario laboral. Ninguna de las dos opciones es buena.
El stack open source: Grafana + Loki + Prometheus
A diferencia de Elasticsearch, Loki no indexa el contenido completo de cada línea de log. Indexa solo los labels y almacena los logs comprimidos. Esto lo hace dramáticamente más barato de operar. Y al usar S3 como backend, el storage es el más barato y duradero de AWS.
Es 100% open source — sin licencias por usuario, sin costos por volumen de ingesta, sin sorpresas en la factura. Es el estándar de facto para observabilidad en Kubernetes. ¿El problema? Instalarlo es fácil. Tenerlo configurado para que sea realmente útil es otra historia.
Lo que implica tener este stack funcionando de verdad
La instalación no es un helm install y listo. El stack tiene múltiples componentes que necesitan coordinarse:
- Prometheus: decidir cuántos días de retención, cuánto storage asignar, cada cuánto scrappear métricas (más frecuente = más storage = más costo), y cómo dimensionar la memoria para que no se caiga bajo carga.
- Loki + agente recolector: configuración de almacenamiento en S3 (bucket, permisos IAM, esquema de indexación), retención de logs, límites de queries para que una búsqueda pesada no tumbe el servicio, y un agente corriendo en cada nodo.
- Grafana: persistencia para no perder dashboards ante reinicios, configuración de data sources apuntando a Prometheus y Loki, y mecanismos para cargar dashboards automáticamente.
Un error en la configuración de networking puede significar que Loki esté enviando tráfico por internet público en lugar de por la red interna — convirtiendo un costo de centavos en una factura de cientos de dólares por data transfer.
Un equipo que lo hace por primera vez invierte fácilmente 2 a 4 semanas antes de tener dashboards realmente útiles. Y muchos nunca llegan al punto donde la observabilidad les dice cosas accionables — se quedan en “tenemos Grafana instalado” sin que nadie lo use.
Caso práctico: configurar requests y limits correctamente
Supongamos que tenés un servicio de API con 512Mi de memory request y 500m de CPU request. Sin Grafana, esta configuración es una apuesta. ¿Está bien? ¿Es mucho? ¿Es poco? No hay forma de saberlo sin datos.
Con un dashboard bien configurado, descubrís esto:
Kubernetes cree que tus pods necesitan mucho más de lo que realmente usan. Karpenter provisiona nodos más grandes de lo necesario. Multiplicá esta corrección por cada servicio en tu cluster y la cantidad de nodos necesarios se reduce significativamente — lo cual se traduce directamente en menos plata en tu factura de AWS.
Pero para llegar a este insight necesitás el stack corriendo, dashboards con las queries correctas, y días o semanas de datos históricos. Sin observabilidad, estás adivinando.
Logs centralizados y alertas: de ver a actuar
Sin Loki, debuggear un error en producción significa conectarse al cluster, listar los 47 pods de tu servicio, abrir los logs de uno, buscar el error, no encontrarlo, abrir los logs del siguiente, y repetir. Y si el pod ya se recicló, los logs simplemente no existen.
Buscás por namespace, servicio y palabra clave, y en segundos tenés los logs de todos los pods filtrados. Podés correlacionar un spike de errores con un aumento de latencia en las métricas de Prometheus, identificar exactamente qué endpoint está fallando, y ver en qué momento empezó — todo en la misma interfaz.
El paso final es configurar alertas que disparen notificaciones cuando algo está mal. Pero cada alerta necesita tuning:
- Umbrales incorrectos generan ruido (alert fatigue) y el equipo empieza a ignorar todas las notificaciones.
- Umbrales muy altos y te enterás tarde — cuando el problema ya afectó a usuarios.
- Configurar rutas de notificación, definir quién responde a qué, y mantener las reglas actualizadas a medida que tus servicios cambian es trabajo continuo.
| Componente | Qué implica configurar |
|---|---|
| Prometheus | Instalación, storage, retención, scrape config, tuning de recursos |
| Loki + agente | Storage en S3, permisos IAM, esquema de labels, retención, networking |
| Grafana | Data sources, persistencia, carga automática de dashboards |
| Dashboards útiles | Decenas de paneles con queries de PromQL por servicio y namespace |
| Alertas | Reglas con umbrales correctos, rutas de notificación, mantenimiento continuo |
| Networking | Tráfico interno para evitar costos ocultos de data transfer |
| Sin observabilidad | Con SleakOps |
|---|---|
| Instalar y configurar Prometheus + Loki + Grafana manualmente | Stack completo pre-instalado — listo desde el día uno |
| Configurar S3, IAM y networking para Loki | Storage y redes optimizadas por defecto |
| Perder logs cuando pods mueren o Spots se interrumpen | Logs persistentes sobre S3 con retención configurada |
| Aprender PromQL para crear queries útiles | Dashboards preseteados listos para usar |
| Adivinar requests y limits sin datos | Panel de right-sizing con datos reales de uso |
| Pagar USD 500–2.000/mes por herramientas SaaS | Stack open source optimizado por USD 30/mes |
Observabilidad real desde el primer día
Cuando levantás tu infraestructura con SleakOps, Grafana, Loki y Prometheus ya están corriendo con dashboards preseteados que te muestran exactamente lo que necesitás ver — sin escribir una sola query de PromQL.
Conocé SleakOps →