Monitoreo de servicios de Golang con Prometheus: elección entre modelos de inserción y extracción

¿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:

1. Modelo de extracción : Prometheus consulta activamente a los servicios para conocer sus métricas.
2. Modelo Push (Pushgateway) : los servicios envían sus métricas a un intermediario, que luego Prometheus recopila.

Vamos a desglosarlos.

Modelo de tracción

En el modelo de extracción , Prometheus obtiene activamente métricas de su aplicación a través de HTTP (por ejemplo, http://your-service:8080/metrics ).

Este es el método predeterminado y el más utilizado.

Configuración de Prometheus con Golang (modelo Pull)

1. Instalar las librerias necesarias:

    go get github.com/prometheus/client_golang/prometheus go get github.com/prometheus/client_golang/prometheus/promhttp

   
   

2. Define tus métricas (por ejemplo, contar solicitudes HTTP):

    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", })

   
   

3. Exponer un punto final /metrics :

    import ( "net/http" "github.com/prometheus/client_golang/prometheus/promhttp" ) func main() { http.Handle("/metrics", promhttp.Handler()) }

   
   

4. Configure Prometheus para extraer métricas de su servicio en prometheus.yml :

    scrape_configs: - job_name: "example_service" static_configs: - targets: ["localhost:8080"]

Ahora, Prometheus consultará automáticamente http://localhost:8080/metrics cada pocos segundos para recopilar datos.

¿Por qué se prefiere el modelo Pull?

• Simplicidad : Prometheus controla el cronograma y la frecuencia del raspado.
• Menos puntos de falla : no es necesario un servicio adicional para recibir métricas.
• Limpieza automática : si un servicio deja de responder, Prometheus simplemente deja de recibir datos, evitando métricas obsoletas.

Modelo Push (enfoque Pushgateway)

En el modelo push , un servicio envía sus métricas a un servicio intermediario llamado Pushgateway , que las almacena hasta que Prometheus las recupera.

Cómo funciona (modelo Push)

1. Su aplicación envía métricas a Pushgateway:

    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) } }

   
   

2. Configurar Prometheus para recopilar datos de Pushgateway:

    scrape_configs: - job_name: "pushgateway" static_configs: - targets: ["localhost:9091"]

¿Cuándo es realmente útil el modelo Push?

• Trabajos de corta duración (tareas por lotes, trabajos cron) que se completan antes de que Prometheus pueda extraerlos.
• Restricciones de red donde Prometheus no puede acceder directamente al servicio.
• Fuentes de datos externas (dispositivos IoT, API externas) que no se pueden extraer directamente.

¿Qué modelo deberías utilizar?

¿Por qué el modelo Push no es ideal?

Aunque Pushgateway resuelve algunos problemas (por ejemplo, procesos de corta duración que finalizan antes de que Prometheus los elimine), introduce varios problemas nuevos :

1. 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 push.Delete(...) o configurar políticas de vencimiento.

     
     

2. Complejidad adicional

   • En lugar de un enlace directo Servicio → Prometheus , ahora tiene Servicio → Pushgateway → Prometheus .

   • Pushgateway es una dependencia adicional que aumenta la carga de mantenimiento.

     
     

3. 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.

     
     

4. 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 modelo pull es la mejor opción: es simple, eficiente y garantiza datos actualizados sin complejidad adicional. Sin embargo, si trabaja con procesos de corta duración , como funciones Lambda o trabajos por lotes, el modelo push a través de Pushgateway puede ser útil para capturar métricas antes de que finalice el proceso.

Elegir el enfoque correcto garantiza una mejor observabilidad y capacidad de mantenimiento de su sistema.

¡Cuidarse!