¿Qué es Prometeo y por qué lo necesitas? Prometheus es un potente sistema de monitoreo que recopila y procesa datos numéricos (métricas) de las aplicaciones. Le ayuda a realizar un seguimiento de indicadores clave como: El número de solicitudes gestionadas por su servicio. El tiempo de respuesta para cada solicitud. Uso de memoria y CPU. El número de errores que ocurren en el sistema. Al utilizar Prometheus, puedes responder preguntas críticas como: "¿Mi servicio está funcionando eficientemente?" "¿Cuáles son los cuellos de botella en el rendimiento?" "¿Necesitamos ampliar nuestra infraestructura?" ¿Y cómo recopila métricas Prometheus? Hay dos formas principales en las que Prometheus recopila datos: : Prometheus consulta activamente a los servicios para conocer sus métricas. Modelo de extracción : los servicios envían sus métricas a un intermediario, que luego Prometheus recopila. Modelo Push (Pushgateway) Vamos a desglosarlos. Modelo de tracción En el , Prometheus métricas de su aplicación a través de HTTP (por ejemplo, ). modelo de extracción obtiene activamente http://your-service:8080/metrics Este es el método predeterminado y el más utilizado. Configuración de Prometheus con Golang (modelo Pull) Instalar las librerias necesarias: go get github.com/prometheus/client_golang/prometheus go get github.com/prometheus/client_golang/prometheus/promhttp (por ejemplo, contar solicitudes HTTP): Define tus métricas import ( "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promauto" ) var httpRequestsTotal = promauto.NewCounter(prometheus.CounterOpts{ Name: "http_requests_total", Help: "Total number of HTTP requests", }) punto final : Exponer un /metrics import ( "net/http" "github.com/prometheus/client_golang/prometheus/promhttp" ) func main() { http.Handle("/metrics", promhttp.Handler()) } en : Configure Prometheus para extraer métricas de su servicio prometheus.yml scrape_configs: - job_name: "example_service" static_configs: - targets: ["localhost:8080"] Ahora, Prometheus consultará automáticamente cada pocos segundos para recopilar datos. http://localhost:8080/metrics ¿Por qué se prefiere el modelo Pull? : Prometheus controla el cronograma y la frecuencia del raspado. Simplicidad : no es necesario un servicio adicional para recibir métricas. Menos puntos de falla : si un servicio deja de responder, Prometheus simplemente deja de recibir datos, evitando métricas obsoletas. Limpieza automática Modelo Push (enfoque Pushgateway) En el , un servicio sus métricas a un servicio intermediario llamado , que las almacena hasta que Prometheus las recupera. modelo push envía Pushgateway Cómo funciona (modelo Push) Su aplicación a Pushgateway: envía métricas import ( "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/push" ) func main() { registry := prometheus.NewRegistry() jobCounter := prometheus.NewCounter(prometheus.CounterOpts{ Name: "job_execution_count", Help: "Number of executed jobs", }) registry.MustRegister(jobCounter) jobCounter.Inc() err := push.New("http://localhost:9090", "my_service_or_job"). Collector(jobCounter). Grouping("instance", "worker_1"). Push() if err != nil { panic(err) } } Configurar Prometheus para recopilar datos de Pushgateway: scrape_configs: - job_name: "pushgateway" static_configs: - targets: ["localhost:9091"] ¿Cuándo es útil el modelo Push? realmente que se completan antes de que Prometheus pueda extraerlos. Trabajos de corta duración (tareas por lotes, trabajos cron) donde Prometheus no puede acceder directamente al servicio. Restricciones de red (dispositivos IoT, API externas) que no se pueden extraer directamente. Fuentes de datos externas ¿Qué modelo deberías utilizar? Método Mejor para... Ventajas Contras Tirar (recomendado) Servicios web, API, aplicaciones de larga duración Configuración sencilla, menos dependencias, limpieza automática No apto para tareas de muy corta duración. Empujar (Puerta de entrada) Trabajos por lotes, tareas sin acceso estable a la red Permite enviar datos desde trabajos de corta duración Datos obsoletos, complejidad adicional, riesgo de cuellos de botella ¿Por qué el modelo Push no es ideal? Aunque resuelve algunos problemas (por ejemplo, procesos de corta duración que finalizan antes de que Prometheus los elimine), : Pushgateway introduce varios problemas nuevos Es difícil gestionar datos obsoletos Si un servicio muere, sus métricas antiguas permanecen en Pushgateway. Prometeo no tiene forma de saber si el servicio todavía está funcionando. Debe eliminar manualmente las métricas obsoletas mediante o configurar políticas de vencimiento. push.Delete(...) Complejidad adicional En lugar de un enlace directo , ahora tiene . Servicio → Prometheus Servicio → Pushgateway → Prometheus Pushgateway es una dependencia adicional que aumenta la carga de mantenimiento. Posibles cuellos de botella Si muchos servicios envían métricas con frecuencia, Pushgateway puede verse abrumado. A diferencia de los raspados directos de Prometheus (que distribuyen la carga), todas las solicitudes llegan a una única instancia de Pushgateway. Problemas de consistencia de los datos Si varios servicios envían métricas con el mismo nombre pero valores diferentes, es posible que se sobrescriban los datos, lo que genera resultados incorrectos. Conclusión Prometheus es una herramienta potente y confiable para monitorear servicios. Para la mayoría de las aplicaciones, el es la mejor opción: es simple, eficiente y garantiza datos actualizados sin complejidad adicional. Sin embargo, si trabaja con , como funciones Lambda o trabajos por lotes, el a través de Pushgateway puede ser útil para capturar métricas antes de que finalice el proceso. modelo pull procesos de corta duración modelo push Elegir el enfoque correcto garantiza una mejor observabilidad y capacidad de mantenimiento de su sistema. ¡Cuidarse!
