Monitorización ligera de servidores para un VPS: Beszel vs Netdata vs Uptime Kuma vs Nezha (y cuándo no necesitas ninguno)

15 oct 2026 · Termalin Team vpslinuxcomparisontoolshomelab

Para el monitoreo ligero de un VPS o de un puñado de ellos, la lista corta y honesta es de verdad corta, y la elección correcta depende de la pregunta que te hagas. Si quieres saber si tus máquinas están sanas, usa Beszel. Si quieres saber si los usuarios pueden abrir tu sitio, usa Uptime Kuma. Para un panel de una flota de VPS repartida por regiones, usa Nezha; para una sola máquina ahora mismo, Glances; y para el detalle al segundo durante un incidente, Netdata. La mayoría de la gente necesita una de estas, a veces dos, y rara vez una pila de observabilidad completa.

Para que conste: nosotros hacemos Termalin, que es una de las opciones de abajo. Las herramientas de código abierto están descritas a partir de su documentación pública, consultada el 15 de octubre de 2026, y varias de ellas ganan filas sin discusión.

Este artículo cubre qué vigila cada herramienta, cuánto cuesta de verdad lo «ligero» y las partes que los primeros resultados se saltan: quién vigila al monitor cuando el propio VPS se cae, cómo evitar que las alertas se conviertan en ruido, un pequeño script de reserva y cómo monitorizar una máquina que no tiene ningún puerto abierto.

La respuesta corta: qué herramienta para qué pregunta

Beszel — «¿están bien mis máquinas?». Un hub más un agente diminuto en cada servidor. Indicadores del host y estadísticas de Docker, con alertas a Telegram y más. La opción ligera por defecto.
Netdata — «¿qué pasó en ese segundo exacto?». Métricas al segundo y un detalle profundo por proceso. El más ávido de datos de la lista, que es justo su razón de ser.
Uptime Kuma — «¿puede el mundo exterior llegar a mi servicio?». Comprobaciones HTTP, TCP, ping y DNS con páginas de estado. No vigila CPU, memoria ni disco.
Nezha — «¿cómo va mi flota de VPS, entre proveedores y regiones?». Un panel tipo sonda con terminal web, popular para montajes multirregión.
Glances — «¿qué está haciendo esta máquina ahora mismo?». Una vista en vivo, como htop o btop con más cosas en pantalla. No es una herramienta de alertas.
Termalin — «vigila mis servidores y avísame, sin instalar nada extra». La monitorización va montada sobre un connector de acceso SSH que ya tienes. De pago, y con límites reales (abajo).

Qué significa de verdad «ligero» en la monitorización de servidores

«Ligero» se suele medir por la memoria del agente, que es el número equivocado. Cuenta el conjunto entero:

El agente en cada máquina — normalmente un único binario compilado, pequeño por diseño.
El hub o el panel — aquí es donde está el peso: una aplicación web, a menudo una base de datos, corriendo en algún sitio que se mantiene encendido.
Los puertos abiertos — cada puerto a la escucha es superficie de ataque que ahora te toca a ti.
Contenedores y servicios que parchear — una cosa más que mantener actualizada, para siempre.

Con esa vara, Beszel (un agente + un contenedor para el hub) y Uptime Kuma (un contenedor) son de verdad ligeros. La recopilación al segundo de Netdata es la más ávida de recursos de este grupo, tanto en CPU como en almacenamiento — es el precio de su resolución. Y la clásica «pila grande» — Prometheus más node_exporter más Grafana más Alertmanager — son cuatro piezas móviles que desplegar, asegurar y parchear. Es excelente, pero no es ligera, y para uno a veinte servidores suele ser más de lo que el trabajo necesita.

Los candidatos

Beszel

Un hub (construido sobre PocketBase) más un pequeño agente en Go en cada servidor. El agente puede funcionar de dos formas: el hub se conecta a él por SSH en el puerto 45876, o el agente marca hacia fuera al hub por un WebSocket con un token — el segundo modo no necesita ningún puerto de entrada y funciona detrás de NAT. Lee los indicadores del host y las estadísticas de los contenedores Docker, y alerta sobre CPU, memoria, disco, ancho de banda, temperatura y estado activo/caído, a más de 25 canales, incluidos Telegram y ntfy. Con licencia MIT; la documentación va por la v0.21 al momento de escribir esto. Esta es la herramienta a batir para el simple «¿están sanas mis máquinas?».

Netdata

Métricas al segundo con un panel en vivo denso y mucho detalle automático por proceso y por servicio. El agente es gratuito y corre sin límite en tus propios hosts, sirviendo su propio panel en local. Netdata Cloud, que une los agentes entre sí y encamina las notificaciones, es gratis en el nivel Community hasta 5 nodos conectados; a partir de ahí es Homelab a $90/año (sin límite, con uso razonable) o Business a $4.50/nodo al mes facturado anualmente. Recurre a él cuando estés depurando un pico y una media de un minuto resulte demasiado gruesa.

Uptime Kuma

El monitor de disponibilidad autoalojado: comprobaciones HTTP(s), TCP, por palabra clave, ping, DNS, push y de contenedores Docker, más de 90 servicios de notificación y páginas de estado públicas. Unas 92k estrellas en GitHub, MIT. Lo único que conviene dejar claro: Uptime Kuma no recopila CPU, RAM ni disco del host — vigila si los servicios responden, desde fuera. Eso lo convierte en el compañero natural de una herramienta de indicadores del host, no en su sustituto, y la respuesta habitual a «una alternativa a Uptime Kuma autoalojada» es en realidad «empareja Kuma con Beszel».

Nezha

Un panel más un agente que informa del estado del sistema, ejecuta comprobaciones HTTP/TCP/ping y de caducidad de certificados, lanza alertas, corre tareas programadas y te da una terminal web a cada host. El agente marca hacia fuera al panel. Es el panel «sonda» de VPS de facto en las comunidades de habla china y coreana, y brilla cuando tienes muchos VPS pequeños entre distintos proveedores y regiones y quieres una sola página para todos ellos.

Glances (y htop/btop)

Glances es una vista en vivo de una sola máquina: CPU, memoria, disco, red, procesos y más en una pantalla, por SSH o mediante una página web local opcional. Como htop y btop, responde a «¿qué está haciendo esta máquina ahora mismo?» y nada más — no hay historial ni alertas de verdad. Tenlo en tu caja de herramientas para depurar a mano; no esperes que te avise.

La tabla comparativa

Herramienta	Qué vigila	Alertas y canales	¿Necesita un puerto de entrada?	Coste	Ideal para
Beszel	Indicadores del host + estadísticas de Docker	CPU/mem/disco/ancho de banda/temp/estado; más de 25 canales (Telegram, ntfy)	No en modo WebSocket; sí (`45876`) en modo SSH	Gratis, MIT (autoalojado)	Salud ligera de una flota
Netdata	Indicadores del host, al segundo	Alarmas integradas; notificaciones vía agente o Cloud	Panel local en `19999`; el enlace a Cloud es de salida	Agente gratis; Cloud gratis ≤5 nodos, luego $90/año o $4.50/nodo al mes	Detalle de incidentes en alta resolución
Uptime Kuma	Disponibilidad: HTTP/TCP/ping/DNS/push/contenedores (sin indicadores del host)	Más de 90 servicios; páginas de estado	Sale hacia los objetivos; tú alojas su panel	Gratis, MIT (autoalojado)	Disponibilidad externa + páginas de estado
Nezha	Estado del sistema + HTTP/TCP/ping + caducidad de certificados	Alertas, tareas programadas; terminal web	Los agentes marcan hacia fuera al panel	Gratis (autoalojado)	Panel de VPS multirregión
Glances	Una máquina, en vivo	No es una herramienta de alertas	Local; vista web opcional	Gratis (autoalojado)	Una sola máquina, ahora mismo
Termalin	Indicadores del host por el Connector (sin un segundo agente)	Alertas con umbrales por defecto; correo, push de iOS, Telegram, webhook	No — el Connector es solo de salida	Pro $10/mes o $8/mes anual; Team $15 por usuario	Salud + alertas sin instalar nada

¿Quién vigila al monitor cuando el VPS se cae?

Aquí está el hueco que casi todas las comparativas se saltan. Si tu hub o tu panel corre en el mismo VPS que vigila, se cae con ese VPS — y un servidor muerto no puede avisarte de que está muerto. «Servidor desconectado» es justo la alerta que más quieres, y solo funciona desde un segundo punto de observación.

Tres maneras de cubrirlo:

Un segundo VPS barato en otra ubicación que ejecuta la comprobación externa. Es lo que hacemos nosotros: tenemos Uptime Kuma en un VPS aparte y de bajo coste cuyo único trabajo es darse cuenta de cuándo las máquinas principales dejan de responder.
Un comprobador externo gratuito que hace ping a tus endpoints públicos desde fuera de tu red.
Un servicio alojado cuya lógica de «¿está activo?» corre en una infraestructura que no es tuya, así que sobrevive a la caída de tu máquina.

Elijas lo que elijas, la regla es simple: lo que detecta «desconectado» no puede vivir en la máquina que se desconecta.

Alertas que no te enseñan a ignorarlas

Un monitor que te avisa diez veces por hora acaba silenciado en una semana, y entonces es peor que nada. Las herramientas de serie tienden a ser, o bien mudas hasta que escribes reglas, o bien parlanchinas hasta que las ajustas. En cualquier caso, el trabajo es el mismo:

Un mensaje cuando un problema empieza, uno cuando se resuelve — no un recordatorio cada cinco minutos.
Agrupación — varios problemas en el mismo minuto llegan como un solo mensaje; uno de verdad crítico sigue pasando directo.
Sin repeticiones el mismo día para el mismo problema, salvo que sea crítico y persista.
Un primer día tranquilo, para que una máquina recién vigilada no te suelte de golpe cada unidad fallida y cada certificado caducado que ya tenía.
Silenciar por alerta y por servidor, para que una comprobación ruidosa no te obligue a silenciarlo todo.

Y elige umbrales que signifiquen algo: disco al 90 % de aviso y al 95 % crítico, o con previsión de llenarse en un día; inodes agotándose; un proceso terminado por falta de memoria (OOM); una unidad de systemd fallida; un certificado TLS a 14 días de caducar (crítico a los 3); y «desconectado» solo tras unos minutos, para que un reinicio no sea una alarma. Elijas la herramienta que elijas, este ajuste fino es el verdadero trabajo de la monitorización — más que elegir la herramienta.

La solución de reserva de diez líneas: una alerta de espacio en disco a Telegram

Antes de desplegar nada, puedes cubrir el fallo más común de un VPS — un disco lleno — con cron, df y curl. Esta es la respuesta a «script de alerta de disco lleno en Linux» y a «bot de Telegram para monitorizar un servidor» cuando todavía no quieres un panel.

Mantén los secretos fuera del script. Léelos del entorno:

#!/usr/bin/env bash
# disk-alert.sh — warn via Telegram when a filesystem is too full.
set -euo pipefail

: "${TELEGRAM_BOT_TOKEN:?set TELEGRAM_BOT_TOKEN}"
: "${TELEGRAM_CHAT_ID:?set TELEGRAM_CHAT_ID}"
threshold="${DISK_THRESHOLD:-90}"

df -x tmpfs -x devtmpfs --output=pcent,target | tail -n +2 | while read -r pct mount; do
  used="${pct%\%}"
  [ "$used" -ge "$threshold" ] || continue
  curl -fsS --max-time 15 \
    --data-urlencode "chat_id=${TELEGRAM_CHAT_ID}" \
    --data-urlencode "text=$(hostname): ${mount} is ${used}% full" \
    "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" >/dev/null
done

Pon los valores reales en un archivo accesible solo por root, nunca en el script ni en el crontab:

# /etc/disk-alert.env  — chmod 600, owned by root
export TELEGRAM_BOT_TOKEN=123456789:replace-with-your-bot-token
export TELEGRAM_CHAT_ID=987654321
export DISK_THRESHOLD=90

Luego ejecútalo cada quince minutos con cron. Guarda esta línea como /etc/cron.d/disk-alert (este formato, con un nombre de usuario, es para los archivos de /etc/cron.d/):

*/15 * * * * root . /etc/disk-alert.env && /usr/local/bin/disk-alert.sh

Se repite cada quince minutos mientras el disco siga lleno. Para una alerta de último recurso eso es a propósito; si es demasiado ruidosa, ejecútalo cada hora.

Crea un bot con @BotFather, envíale un mensaje para que pueda responderte, y lee tu chat_id una vez desde getUpdates. Eso es todo: sin agente, sin puerto, sin panel. No escalará más allá de unas pocas máquinas, pero atrapará el fallo que tumba a la mayoría de los VPS.

Monitorización detrás de NAT, CGNAT o sin puertos abiertos

Una máquina detrás de NAT o CGNAT no puede aceptar una conexión entrante, así que cualquier monitor que funcione conectándose a la máquina queda descartado. Los que sí funcionan comparten todos una misma forma: la máquina sale hacia fuera:

Beszel en modo WebSocket: el agente marca hacia fuera al hub, sin puerto de entrada. (El modo SSH necesita el 45876 de entrada, así que evítalo aquí.)
Netdata: el enlace del agente con Netdata Cloud es de salida.
Uptime Kuma: usa un monitor push — la máquina llama a una URL de Kuma de forma periódica, y Kuma alerta cuando las llamadas se detienen.
Termalin: el Connector es solo de salida y nunca escucha en un puerto.

La técnica general — y por qué «deja que salga hacia fuera» es la única respuesta segura para una máquina privada — está en SSH detrás de NAT sin reenvío de puertos (en inglés), y la versión para laboratorio doméstico está en SSH a un NAS o servidor doméstico.

Dónde encaja Termalin — y dónde no

El enfoque de Termalin es distinto del de las herramientas de arriba: no añade ningún agente de monitorización. Si un servidor ya tiene un Connector de Termalin — el mismo agente de salida y sin puerto de entrada que usas para el acceso SSH sin claves — entonces ya está monitorizado. No hay un segundo agente: una vez por minuto Termalin ejecuta unos pocos comandos de solo lectura (/proc, df, ps y similares) por la conexión que el Connector ya mantiene. Al servidor le cuesta unos milisegundos de CPU y alrededor de un kilobyte por minuto.

Lo que lee es el cuadro de salud habitual: CPU (incluidos iowait y steal), carga y presión, memoria y swap, espacio en disco e inodes, E/S de disco y de red, sockets y archivos abiertos, procesos, contenedores, servicios fallidos, inicios de sesión SSH fallidos, actualizaciones de seguridad pendientes, puertos a la escucha y certificados TLS con los días que les quedan para caducar. Las alertas funcionan con umbrales por defecto y sin reglas que escribir, y están hechas para mantenerse calladas: una al empezar, una al acabar, agrupadas, sin repeticiones el mismo día, un primer día tranquilo y silenciado por alerta. Llegan al correo, al push de iOS, a Telegram (un toque conecta el bot) y a un webhook que Slack y Discord aceptan, firmado con HMAC-SHA256. El historial es de 90 días en Pro y dos años en Team.

Como un asistente de IA puede leer los mismos datos por el endpoint MCP alojado de Termalin (server_metrics y alerts_list), también puedes preguntar sin más «¿cómo van mis servidores?» en Claude o ChatGPT y obtener la respuesta a partir de los datos recopilados. En la terminal web, selecciona un error en la salida y elige «Explicar la selección»: el asistente escribe un diagnóstico breve en lenguaje llano y termina con unos cuantos comandos de comprobación de solo lectura que un botón teclea por ti en la sesión. El cuadro completo está en la página de monitorización de servidores.

Ahora los límites honestos, porque las herramientas de código abierto lo superan en varios de ellos:

Sin comprobaciones de disponibilidad externas y sin páginas de estado. Es una herramienta de indicadores del host y alertas, no un monitor de disponibilidad — Uptime Kuma lo sigue complementando.
Sin recogida de logs y sin métricas personalizadas. No sustituye a Grafana ni a Prometheus.
Los paneles están solo en el panel web por ahora, no en la app de escritorio — aunque la app de escritorio sí muestra en vivo la CPU, la memoria y el disco de un host conectado en su barra de estado y en el watch grid (en inglés).
Sin cifrado de extremo a extremo — estas cifras se guardan de forma que el servicio puede leerlas, porque tiene que leerlas para dibujar las gráficas y lanzar las alertas.
No está en el plan Free. Necesita un Connector, que forma parte de Pro ($10/mes, o $8/mes facturado anualmente — $96/año) y Team ($15 por usuario), con 14 días de Pro de prueba que no piden tarjeta.

Si «gratis y autoalojado» es un requisito innegociable, Beszel o Uptime Kuma es tu respuesta, y es una decisión razonable. El caso de Termalin es más estrecho: ya lo usas para el acceso SSH, y prefieres no montar y cuidar una pila de monitorización aparte solo para tener gráficas de salud y alertas sensatas.

Recomendaciones según el caso

Un VPS de aficionado. Beszel para la salud, o simplemente el script de cron de arriba si lo único que temes es un disco lleno. Añade Uptime Kuma más tarde si tienes un sitio público.
De 5 a 20 VPS entre proveedores (Hetzner, Contabo, Hostinger, un droplet o dos). Beszel para las métricas más Uptime Kuma para la disponibilidad, con la instancia de Kuma en una máquina aparte. Si prefieres un solo panel con terminal web, Nezha. Si ya usas Termalin para SSH, activa su monitorización y ahórrate la pila extra.
Un laboratorio doméstico detrás de CGNAT. Cualquier cosa solo de salida: Beszel en modo WebSocket, Netdata hacia Cloud, o un monitor push de Kuma — mira la guía de detrás de NAT (en inglés).
«Quiero que mi asistente de IA responda a ‹cómo van mis servidores›». Ese es el caso de Termalin: los mismos datos que ve una persona, leídos por el agente a través de MCP.

Preguntas frecuentes

¿Es Netdata gratis? El agente es gratuito y corre sin límite en tus propios hosts, con su propio panel local. El nivel Community de Netdata Cloud es gratis hasta 5 nodos conectados; más allá de eso es Homelab a $90/año o Business a $4.50/nodo al mes facturado anualmente.

¿Uptime Kuma vigila la CPU, la memoria o el disco? No. Uptime Kuma comprueba si los servicios responden — HTTP, TCP, ping, DNS, contenedores y push — desde fuera. Para la CPU, la RAM y el disco del host, emparéjalo con Beszel, Netdata o Termalin.

Beszel vs Netdata: ¿cuál es más ligero? Beszel. Es un pequeño agente por máquina más un único hub. Netdata recopila al segundo y es el más ávido de recursos de este grupo; lo eliges por resolución, no por ser ligero.

¿Cuál es la mejor monitorización gratuita de VPS con alertas por Telegram? Para la salud del host, Beszel envía a Telegram y es gratis de autoalojar. Para la disponibilidad, Uptime Kuma también. Como apaño sin instalar nada, el script de cron + curl de arriba envía directo a Telegram sin nada corriendo en segundo plano.

¿Cómo monitorizo un VPS detrás de NAT o sin puertos abiertos? Usa una herramienta donde la máquina salga hacia fuera: Beszel en modo WebSocket, el agente de Netdata hacia Cloud, un monitor push de Kuma o un Connector de Termalin. Ninguno necesita un puerto de entrada. Mira SSH detrás de NAT sin reenvío de puertos (en inglés).

Termalin es un cliente SSH multiplataforma; en Pro y Team, cada servidor que tiene un Connector se monitoriza con gráficas y alertas de umbral por defecto, y no se instala nada extra en la máquina — mira la monitorización de servidores o descárgalo.