Cuando algo falla en producción a las tres de la mañana, la diferencia entre una noche horrible y un susto de diez minutos suele ser la misma: tener buena monitorización. Después de años montando plataformas, si tuviera que quedarme con una sola pareja de herramientas de observabilidad, seguiría eligiendo Prometheus y Grafana. Hoy os cuento por qué, y cómo empezar sin morir en el intento.
Qué aporta Prometheus
Prometheus es una base de datos de series temporales con un modelo muy particular: en lugar de esperar a que le envíen datos, va él mismo a buscarlos. Cada pocos segundos hace scraping de un endpoint HTTP (normalmente /metrics) que exponen tus aplicaciones y exporters. Ese modelo pull tiene ventajas enormes: sabes al instante si un servicio ha dejado de responder, y añadir un objetivo nuevo es tan simple como declararlo en la configuración o dejar que el service discovery lo encuentre solo.
Su lenguaje de consultas, PromQL, es lo que lo convierte en algo más que un almacén de métricas. Te permite responder preguntas concretas: qué porcentaje de peticiones está fallando, cuánto tarda el percentil 99 de latencia, a qué ritmo crece el uso de disco. Un ejemplo clásico para ver el ratio de errores de un servicio:
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))Y dónde entra Grafana
Prometheus almacena y consulta; Grafana visualiza y da contexto. Conectas Prometheus como datasource en dos clics y a partir de ahí construyes dashboards con paneles, variables y alertas visuales. La gracia de Grafana es que no se limita a Prometheus: puedes mezclar en un mismo dashboard métricas, logs de Loki y trazas de Tempo, y pasar de una gráfica rara a los logs exactos de ese instante.
Cómo empezar con buen pie
- Empieza por los exporters estándar: node_exporter para máquinas, kube-state-metrics si estás en Kubernetes y el exporter oficial de tu base de datos. Con eso ya cubres el ochenta por ciento de los sustos.
- Instrumenta tus aplicaciones con las cuatro señales doradas: latencia, tráfico, errores y saturación. Si solo mides una cosa, que sea el ratio de errores visto por el usuario.
- Usa los dashboards de la comunidad como punto de partida: en la web de Grafana hay miles listos para importar. Ajústalos en lugar de partir de un lienzo en blanco.
- Alerta sobre síntomas, no sobre causas: avisa cuando el usuario sufre (errores, latencia), no cada vez que una CPU pasa del ochenta por ciento. Tu yo de guardia lo agradecerá.
- Vigila la cardinalidad: cada combinación de etiquetas crea una serie nueva. Meter identificadores de usuario o peticiones como labels es la receta clásica para tumbar tu Prometheus.
Errores que veo una y otra vez
El primero: montar el stack y no definir ninguna alerta, con lo que los dashboards se convierten en decoración. El segundo, el contrario: alertar de todo, hasta que el equipo silencia el canal y se pierde lo importante. Y el tercero: olvidar que Prometheus, por defecto, guarda los datos en local; si necesitas retención larga o alta disponibilidad, te tocará mirar soluciones como Thanos o Mimir, pero mi consejo es no complicarse hasta que duela de verdad.
Conclusión
Prometheus y Grafana siguen siendo, para mí, la puerta de entrada más sólida al mundo de la observabilidad: estándar de facto, comunidad gigante y una curva de aprendizaje muy razonable. Si aún no tienes métricas de tus servicios, montar este dúo en un entorno de pruebas es un proyecto perfecto de fin de semana.
¿Y tú, qué stack de monitorización usas en tu día a día? Te leo en los comentarios 😊