Monitoreo de video con Go y Prometheus en 2026
Si corrés una plataforma de video en hosting compartido y querés saber si tus endpoints están caídos antes que tus usuarios, un binario Go liviano con métricas Prometheus es la opción más razonable que existe hoy. El artículo publicado el 11 de mayo de 2026 en Dev.to por Ahmet Gedik documenta exactamente eso: cómo construyeron el sistema de monitoreo y alertas de hosting para DailyWatch.video sin instalar un stack de monitoreo completo.
En 30 segundos
- El sistema corre como un binario Go en hosting compartido con LiteSpeed, sin dependencias externas pesadas.
- Chequea tres tipos de endpoints: homepage, API de búsqueda (
/search?q=test&format=json) y sitemap XML, de forma concurrente con goroutines. - Expone métricas en formato Prometheus:
video_platform_up,video_platform_latency_msyvideo_platform_uptime_24hen el puerto 9090. - Guarda los últimos 100 resultados de checks y dispara alertas cuando un endpoint cae.
- Prometheus scrapea el endpoint
/metricsautomáticamente, sin agente instalado en el servidor.
Hosting es un servicio que aloja sitios web, aplicaciones y datos en servidores conectados a internet, ofrecido por proveedores especializados desde los años 90. Permite que organizaciones accedan a infraestructura web sin inversión propia en servidores.
Por qué monitoreo personalizado para plataformas de video
Un monitor de infraestructura de video es un sistema que verifica periódicamente la disponibilidad y latencia de los endpoints de una plataforma de streaming, expone métricas en un formato estándar como Prometheus, y dispara alertas cuando algo falla. Eso es la definición de libro. La realidad de implementarlo en hosting compartido es bastante diferente.
Ponele que tenés DailyWatch corriendo en un plan LiteSpeed compartido (que no es poca cosa para video). Instalar Datadog, New Relic o cualquier herramienta de monitoreo empresarial requiere acceso root, agentes en el servidor, y normalmente facturación mensual que escala con los hosts monitoreados. Para un equipo chico, eso es un overhead que no cierra.
La alternativa que documenta el artículo de Gedik es un binario Go que hace exactamente lo que necesitás: HTTP checks, métricas Prometheus, alertas automáticas. Sin instalación en el servidor objetivo. Sin root. Sin costos extra.
Configuración de health checks en JSON
Todo arranca con una config JSON que define qué chequeás y cómo. Para DailyWatch, la estructura incluye tres endpoints con validaciones específicas por tipo:
- Homepage (
https://dailywatch.video): GET, validación de status code 200, sin validación de body. - API de búsqueda (
/search?q=test&format=json): GET con validación de status y contenido del body — chequeá que la respuesta incluya el string esperado. - Sitemap XML (
/sitemap.xml): GET, validación de status y presencia de estructura XML.
Cada endpoint en la config lleva su método HTTP, el status code esperado, el string a buscar en el body (si aplica), y el timeout. Si la creación del request falla por cualquier razón, el sistema lo loggea con el formato "request creation failed: %v" antes de seguir con el siguiente. Eso es manejo de errores a nivel de configuración, no a nivel de código disperso. Lo explicamos a fondo en infraestructura y configuración de hosting.
El User-Agent que manda el monitor es DailyWatch-Monitor/1.0. Detalle chico pero importante: si revisás logs de acceso en el servidor, sabés exactamente qué tráfico viene del monitor propio y no lo confundís con crawlers externos.
Ejecución concurrente de checks con Go
Acá viene lo bueno: Go hace concurrencia sin drama. En vez de chequeár cada endpoint en secuencia (homepage, esperás, search, esperás, sitemap), el sistema lanza goroutines para todos al mismo tiempo.
El resultado práctico es que si tenés 10 endpoints con timeouts de 5 segundos cada uno, el check total tarda 5 segundos, no 50. Para plataformas de video donde la degradación puede ser parcial (el sitemap levantado pero la API caída), esto importa: detectás el problema en el primer ciclo, no después de recorrer toda la lista.
El sistema guarda los últimos 100 resultados de cada check. Eso da contexto histórico sin consumir memoria de forma descontrolada. ¿Alguien validó si 100 es el número correcto para todos los casos? No, pero para la mayoría de equipos chicos que quieren ver tendencias de la última hora, zafa.
Exposición de métricas en formato Prometheus
El monitor expone un endpoint /metrics en el puerto 9090 en formato text/plain; version=0.0.4, que es exactamente lo que Prometheus espera para scraping. Las tres métricas que expone:
| Métrica | Tipo | Descripción | Labels |
|---|---|---|---|
video_platform_up | Gauge (0/1) | Si el endpoint está arriba o no | name, url |
video_platform_latency_ms | Gauge (float) | Latencia del último check en milisegundos | name |
video_platform_uptime_24h | Gauge (float %) | Porcentaje de uptime en las últimas 24h | name |
Cada métrica lleva labels con el nombre del endpoint y la URL. Eso significa que en Prometheus podés filtrar por name="search-api" y ver solo el comportamiento de ese endpoint, sin mezclar todo en una sola serie temporal. Esto se conecta con lo que analizamos en pipelines de CI/CD y deployment automático.
El formato de exposición es texto plano, lo que permite también leerlo con curl localhost:9090/metrics directamente. Para debugging, es mucho más útil de lo que parece.
Alertas automáticas en tiempo real
Cuando un endpoint está DOWN, el sistema loggea con el formato "ALERT: %s is DOWN - %s" donde el segundo campo es la razón del fallo. Sin webhooks, sin PagerDuty, sin integraciones externas en la implementación base. La alerta es un log.
¿Es suficiente? Depende. Si corrés el monitor como un servicio systemd y tenés un agregador de logs que detecta patrones ALERT, es suficiente. Si necesitás que te llegue un mensaje a Slack o un SMS a las 3am, tenés que conectar algo más adelante en el pipeline.
La validación de latencia es más implícita: si el request no termina en el timeout configurado, cuenta como DOWN. No hay umbral de latencia configurable tipo “si tarda más de 2000ms, alertá aunque responda 200”. Eso es una limitación real que habría que agregar si el streaming tiene SLAs de performance ajustados.
Integración con Prometheus para scraping
La configuración del scrape job en Prometheus es estándar: definís el job, apuntás al host donde corre el monitor, Puerto 9090, y Prometheus hace polling automático según el intervalo configurado. Las métricas quedan almacenadas en series temporales que después podés graficar en Grafana. Más contexto en costos de monitoreo administrado vs self-hosted.
La ventaja respecto a soluciones basadas en agentes es que el servidor objetivo no necesita tener nada instalado. El monitor corre en cualquier máquina con red hacia los endpoints que monitoreás. Si usás donweb.com para tu hosting y no tenés acceso root, esto sigue funcionando porque el monitor puede vivir en otro servidor con acceso a internet.
Según el análisis de Pandora FMS sobre Prometheus, el modelo de scraping pull tiene una ventaja operativa: si el monitor falla, Prometheus deja de recibir datos y podés detectar eso como una ausencia de métricas, no como un silencio sin explicación.
Casos de uso en infraestructura de streaming
Más allá de DailyWatch, el patrón aplica a cualquier plataforma que tenga endpoints críticos diferenciados. Pensá en esto: un CDN puede estar respondiendo bien la descarga de video pero la API de metadata puede estar caída, con lo cual los usuarios ven el player pero no pueden cargar el contenido. Sin monitoreo granular por endpoint, eso se ve como “algo está roto” sin poder priorizar.
Con este esquema podés monitorear:
- Endpoints de CDN para entrega de contenido
- APIs de autenticación y sesión
- Endpoints de búsqueda y recomendación
- Sitemaps para SEO (sí, si el sitemap cae, el indexado se frena)
- Health checks de workers de transcodificación si exponés algún endpoint
Las métricas de uptime a 24h en Prometheus, cruzadas con Grafana, dan dashboards de SLA sin comprar herramientas adicionales. Para oncall, una alerta basada en video_platform_up == 0 durante más de N minutos es suficiente para disparar una notificación.
Errores comunes al implementar este tipo de monitoreo
Monitorear solo el status code, ignorar el body
Un servidor puede devolver 200 con un body de error genérico (“Something went wrong”). Si validás solo el status code, tu monitor dice UP cuando el servicio está efectivamente roto. La validación de contenido del body es parte del check, no opcional.
Usar el mismo timeout para todos los endpoints
Un sitemap XML puede pesar varios MB y tardar 3 segundos en responder en condiciones normales. Si le ponés el mismo timeout de 1 segundo que a la homepage, vas a tener falsos positivos constantes. Configurar timeouts por tipo de endpoint es lo mínimo.
No separar el monitor del servidor monitoreado
Si el monitor corre en el mismo servidor que la plataforma, cuando el servidor cae, el monitor también cae y no podés detectar el problema. El monitor tiene que vivir en infraestructura independiente, aunque sea una instancia pequeña en otro proveedor. Sobre eso hablamos en en aspectos técnicos de SEO.
Confundir latencia de red con latencia de aplicación
La latencia que mide este tipo de monitor incluye DNS, TCP handshake, TLS, y tiempo de respuesta de la aplicación. Si el número sube, no sabés automáticamente cuál de esas capas es el problema. Para diagnóstico fino, necesitás métricas más granulares o al menos loggear el tiempo de cada fase del request.
Preguntas Frecuentes
¿Cómo monitorear endpoints de una plataforma de video con Go?
Creás una config JSON con los endpoints a monitorear, el método HTTP, el status esperado y strings a buscar en el body. El programa Go hace HTTP requests concurrentes con goroutines, valida las respuestas, y guarda el resultado. Para exponer las métricas, levantás un servidor HTTP en un puerto dedicado (el ejemplo usa 9090) con un handler que formatea los datos en texto Prometheus.
¿Qué es Prometheus y cómo usar métricas en Go?
Prometheus es un sistema de monitoreo y alertas open source que recolecta métricas haciendo scraping de endpoints HTTP en formato texto. En Go, podés exponer métricas sin la librería cliente oficial simplemente escribiendo el formato correcto (text/plain; version=0.0.4) con las líneas de métrica y sus labels. La librería oficial de Prometheus para Go simplifica esto, pero para métricas simples el formato manual es suficiente.
¿Cómo detectar caídas de servicio en video streaming?
El monitor chequea el endpoint en un intervalo configurado (por ejemplo, cada 60 segundos) y si el HTTP request falla, devuelve un status code inesperado o el body no contiene el string esperado, la métrica video_platform_up pasa a 0. Desde Prometheus o Grafana configurás una alerta que dispare cuando esa métrica esté en 0 por más de N minutos consecutivos, para evitar alertas por fallos transitorios de red.
¿Cómo hacer health checks concurrentes en Go sin herramientas pesadas?
Con goroutines y un sync.WaitGroup lanzás todos los checks al mismo tiempo y esperás que terminen. Cada goroutine hace su HTTP request, valida la respuesta, y escribe el resultado en un slice compartido (protegido con un mutex o usando un channel). El tiempo total del ciclo de checks es igual al del check más lento, no la suma de todos.
¿Cómo validar respuestas de API en monitoreo automático?
Además de validar el status code HTTP, leer el body de la respuesta y buscar un string específico (por ejemplo, la clave JSON que esperás que siempre esté presente) confirma que el servicio no solo responde sino que responde correctamente. Si la API devuelve 200 con {"error": "database connection failed"}, la validación de body lo detecta donde la validación de status code no lo haría. Según el patrón de monitoreo de endpoints de Microsoft, esta validación funcional es parte del health check bien implementado.
Conclusión
Lo que documenta este proyecto es un patrón pragmático para equipos que no quieren pagar por monitoreo empresarial y tienen las habilidades para construir algo propio en Go. El binario corre en hosting compartido, no toca el servidor monitoreado, y expone datos en el formato estándar de facto del ecosistema (Prometheus). Eso no es poco.
Lo que falta, siendo honestos: configuración de umbrales de latencia, integración de notificaciones lista para usar (Slack, PagerDuty, email), y separación de la lógica de alerta del loop principal. Si lo tomás como base y agregás esas tres cosas, tenés un sistema de monitoreo y alertas serio para hosting en producción. Si lo usás tal cual, tenés un punto de partida sólido para proyectos con bajo volumen o para aprender el patrón.
Para plataformas de streaming en crecimiento, monitorear a nivel de endpoint (no solo “¿el server responde?”) marca la diferencia entre detectar un problema en 5 minutos o enterarte cuando los usuarios llevan una hora sin poder ver nada.
