Un reciente artículo de XDA relató una historia familiar: un contenedor muerto estuvo en un homelab durante 64 días, y los monitores populares no lo detectaron. El quid de la cuestión es que la mayoría del monitoreo de homelab es teatro de verificación HTTP. Se comprueba el balanceador de carga, se obtiene una respuesta 200 y se considera todo el stack como saludable mientras un proceso de fondo colapsó hace un mes. Este resumen cubre las mejores aplicaciones para la monitorización de la salud de contenedores homelab en Windows, macOS y Linux, con énfasis en herramientas que observan el contenedor en sí, no solo el puerto frente a él.
Comparación rápida
| Aplicación | Mejor para | Plataformas | Plan gratuito | Precio inicial | Característica destacada |
|---|---|---|---|---|---|
| Uptime Kuma | Verificaciones HTTP y Docker con enrutamiento de alertas | Windows, macOS, Linux | Sí, self-host gratis | Gratis | Docker health probe, decenas de notificadores |
| Beszel | Panel de control homelab basado en agent ligero | Windows, macOS, Linux | Sí, self-host gratis | Gratis | CPU y memoria del contenedor a lo largo del tiempo, huella mínima |
| Dozzle | Seguimiento en vivo de logs de contenedor en hosts | Windows, macOS, Linux | Sí, self-host gratis | Gratis | Logs en tiempo real con filtro y vista swarm |
| Netdata | Métricas de alta frecuencia con detección de anomalías | Windows, macOS, Linux | Sí, community edition | Plan cloud menos de $10/mes | Granularidad por segundo, alertas basadas en ML |
| Glances | Navegador de métricas terminal-first con web UI | Windows, macOS, Linux | Sí, open source | Gratis | Una pantalla para CPU, RAM, disco, contenedores |
| Prometheus + Grafana | Pipeline de métricas real con dashboards | Windows, macOS, Linux | Sí, ambos open source | Gratis | Reglas de Alertmanager en cualquier métrica |
| Zabbix | Plataforma de monitoreo completa con agentes | Windows, macOS, Linux | Sí, open source | Gratis | Plantillas, escalaciones, proxies distribuidos |
| Autoheal | Reinicio automático de contenedores no saludables | Windows, macOS, Linux | Sí, open source | Gratis | Observa HEALTHCHECK y reinicia al fallar |
Qué buscar en un monitor de contenedores
El caso de XDA es instructivo. Un contenedor estaba en ejecución, un puerto estaba abierto, y el proceso dentro se había atascado. El monitor observaba el puerto, así que nada se disparó. Para evitar esto:
- Lee el HEALTHCHECK propio del contenedor, no solo su puerto expuesto
- Alerta sobre bucles de reinicio, no solo sobre fallos
- Observa el volumen de logs, ya que un proceso atascado a menudo deja de registrar
- Cubre el host también, de modo que un disco lleno no rompa silenciosamente cada contenedor
- Notifica en un canal que realmente lees, no solo correo electrónico
1. Uptime Kuma, mejor para verificaciones HTTP y Docker con enrutamiento de alertas
Uptime Kuma es el monitor de disponibilidad self-hosted por defecto por una razón. Se ejecuta como un único contenedor, verifica endpoints HTTP y habla directamente con Docker para el estado del contenedor, por lo que un contenedor detenido dispara una alerta sin necesidad de que falle primero una verificación de puerto.
Dónde falla: los monitores se configuran uno por uno en la UI, lo que está bien para un homelab pequeño y es doloroso para docenas de servicios. Los datos históricos están limitados por el almacén SQLite.
Precios:
- Gratis: open source, sin niveles.
- Pagado: ninguno.
Plataformas: Windows, macOS, Linux vía Docker.
Conclusión: lo primero a instalar cuando un homelab tiene más de tres servicios.
2. Beszel, mejor para un panel de control homelab basado en agent ligero
Beszel es un pequeño agente Go más un hub que renderiza un panel limpio de CPU, RAM, disco y estadísticas de contenedor a lo largo del tiempo. Se ejecuta donde Netdata es demasiado pesado y Uptime Kuma es demasiado binario.
Dónde falla: la capa de alertas es más delgada que un pipeline Prometheus, e integraciones fuera de los notificadores integrados requieren un empalme Webhook.
Precios:
- Gratis: open source, sin niveles.
- Pagado: ninguno.
Plataformas: Windows, macOS, Linux binarios nativos o Docker.
Conclusión: la opción correcta cuando deseas gráficos de historial sin compromiso de Prometheus.
3. Dozzle, mejor para seguimiento en vivo de logs en hosts
Dozzle transmite logs de contenedor en un navegador con filtros, colores de nivel de log y modo swarm que extrae logs de cada host en un panel. Un contenedor que se muere a menudo muestra la falla en sus logs antes de que cambie el health check, y Dozzle es la forma más rápida de verlo.
Dónde falla: es un visor de logs, no un monitor completo, así que emparejarlo con algo que alerte sobre el patrón que identifiques.
Precios:
- Gratis: open source, sin niveles.
- Pagado: ninguno.
Plataformas: Windows, macOS, Linux vía Docker.
Conclusión: la pestaña que mantienes abierta cuando un contenedor comienza a comportarse mal.
4. Netdata, mejor para métricas de alta frecuencia con detección de anomalías
Netdata muestrea cada métrica por segundo y aplica modelos ML que marcan anomalías sin que escribas reglas de alerta. Las caídas de contenedor, los atascos de red y la latencia del disco aparecen en un gráfico en vivo en uno o dos segundos.
Dónde falla: el agente usa más recursos que Beszel o Glances, y el nivel cloud es donde las vistas de múltiples nodos realmente brillan.
Precios:
- Gratis: community edition cubre un nodo con todas las métricas.
- Pagado: plan cloud menos de $10/mes por usuario para agregación de múltiples nodos y notificaciones.
Plataformas: Windows, macOS, Linux.
Conclusión: la opción a elegir cuando un homelab cruzó la línea de “lo suficientemente grande como para necesitar gráficos reales”.
5. Glances, mejor para navegador de métricas terminal-first
Glances muestra CPU, memoria, disco, red y estadísticas de contenedor Docker en una única vista de terminal, y expone la misma vista sobre una web UI cuando deseas una pestaña de navegador. Para un servidor headless, es la forma más rápida de ver qué está pasando ahora.
Dónde falla: el historial está limitado a lo que el proceso mantiene en memoria, y no hay canal de alerta integrado más allá de stdout.
Precios:
- Gratis: open source, sin niveles.
- Pagado: ninguno.
Plataformas: Windows, macOS, Linux.
Conclusión: la segunda pestaña SSH en el monitor de cada administrador de homelab.
6. Prometheus + Grafana, mejor para un pipeline de métricas real
Prometheus recaba métricas, Grafana las renderiza, y Alertmanager enruta alertas a donde quieras. Apunta cAdvisor y node-exporter al mismo Prometheus y tienes CPU por contenedor, memoria, recuento de reinicios y estado de salud en un lenguaje de consulta.
Dónde falla: tres o cuatro partes móviles para configurar, y PromQL requiere un fin de semana para entender. La recompensa es una pila de monitoreo que no supera el homelab.
Precios:
- Gratis: todos los componentes son open source.
- Pagado: existen niveles cloud gestionados pero no son necesarios para un homelab.
Plataformas: Windows, macOS, Linux vía Docker o binarios nativos.
Descargar: Prometheus Grafana cAdvisor
Conclusión: el endgame si planeas crecer el homelab. Excesivo para tres contenedores.
7. Zabbix, mejor para una plataforma de monitoreo completa
Zabbix es un servidor de monitoreo maduro con agentes para cada SO, plantillas para cientos de servicios, y árboles de escalación para alertas. Observa el contenedor, el host y la red desde un único dashboard.
Dónde falla: la UI muestra su edad, y un homelab de cinco contenedores no necesita la superficie operacional que trae Zabbix.
Precios:
- Gratis: open source, sin niveles.
- Pagado: el soporte comercial es opcional.
Plataformas: Windows, macOS, Linux.
Conclusión: elige esto si también administras servidores reales en el trabajo y deseas una herramienta en ambos lados de la valla.
8. Autoheal, mejor para reinicio automático en health checks fallidos
Autoheal es un único contenedor que observa el estado HEALTHCHECK de otros contenedores y reinicia todo lo que reporta no saludable demasiado tiempo. No reporta, actúa, así que un proceso atascado muere y renace antes de que sepas que algo salió mal.
Dónde falla: necesita un HEALTHCHECK real en el Dockerfile o compose file de cada contenedor. Un contenedor sin él es invisible para Autoheal.
Precios:
- Gratis: open source, sin niveles.
- Pagado: ninguno.
Plataformas: Windows, macOS, Linux vía Docker.
Descargar: GitHub
Conclusión: la red de seguridad que añades después de fijar las definiciones de health-check.
Cómo elegir el correcto
- Si tienes tres servicios y quieres una herramienta, instala Uptime Kuma y listo.
- Si quieres historial sin complejidad, empareja Uptime Kuma con Beszel.
- Si necesitas ver por qué un contenedor no está feliz, mantén Dozzle abierto.
- Si quieres detección de anomalías sin escribir reglas, ejecuta Netdata.
- Si vives en terminal, Glances es la pantalla que mantienes.
- Si el homelab está creciendo y planeas añadir servidores, invierte en Prometheus + Grafana ahora.
- Si quieres una plataforma de nivel empresarial con escalaciones, Zabbix es el ajuste.
- Si quieres que los contenedores muertos se arreglen a sí mismos, añade Autoheal.
FAQ
¿Por qué mi monitoreo perdió un contenedor muerto? La causa más común es una verificación que observa el puerto frente al contenedor mientras el proceso detrás se atasca. Mueve la verificación dentro del contenedor usando Docker HEALTHCHECK, o empareja la verificación HTTP con una métrica como recuento de procesos o tasa de líneas de log.
¿Necesito Prometheus para un homelab pequeño? No. Uptime Kuma y Beszel cubren la mayoría de lo que un homelab pequeño necesita. Prometheus se vuelve valioso una vez que deseas historial largo, consultas personalizadas y alertas basadas en reglas en cualquier métrica.
¿Cuál es la mejor opción gratuita? Uptime Kuma, Beszel, Dozzle, Glances, Prometheus, Grafana, Zabbix y Autoheal son todos gratis y open source. Uptime Kuma es el camino más corto desde la instalación a la primera alerta.
¿Puedo usar esto en Windows? Sí. Cada opción aquí se ejecuta en Windows bien de forma nativa o vía Docker Desktop. Uptime Kuma, Beszel, Dozzle, Prometheus y Grafana generalmente se ejecutan como contenedores.
¿Cómo detengo el problema de fatiga de alertas? Enruta alertas a un canal que realmente lees, establece escalación de advertencia a página después de un retraso, y prefiere alertas de síntoma (los usuarios no pueden iniciar sesión) sobre alertas de causa (CPU está al 85 por ciento). Cada herramienta arriba soporta este patrón.