Monitorización self-hosted: de Netdata pasando por Grafana hasta Beszel

La gente llega al self-hosting de distintas formas. En mi caso, como para muchos otros, empezó con una sola aplicación que quería instalar en mi propio servidor. Al principio era sobre todo curiosidad técnica, ganas de entender cómo funciona todo y aprender algo por el camino. Después te enganchas y empiezas a añadir otra aplicación, luego una tercera, una cuarta, y cuando te das cuenta tienes todo un zoológico de servidores, algunos con varias apps cada uno.

Así que tarde o temprano aparece la pregunta: ¿cómo vigilas este zoológico entero de servidores y aplicaciones? Al principio disfrutaba conectándome por SSH a cada servidor a mano, ejecutando las actualizaciones manualmente, mirando las constantes vitales con las utilidades de siempre (top, htop, btop), revisando los logs de las apps, y demás.

TL;DR: Después de Netdata, luego de Grafana + Prometheus, me quedé con Beszel y ojalá lo hubiese encontrado antes. Más abajo explico el porqué con detalle, para quién está pensado y qué cosas no hace Beszel. Esto no es una review de Beszel; va sobre qué soluciones probé y cuál escogí para monitorizar mi pequeña infraestructura.

Pero rápidamente me cansé de jugar a “hacker cool” de película, y todo el asunto se convirtió en una tarea aburrida que no siempre tenía ganas de hacer. Dicho esto, como muchos de esos servidores están expuestos a internet, vigilarlos, actualizar las apps con regularidad, revisar los logs y demás no es opcional. Así que todo self-hoster acaba teniendo que resolver el problema de monitorizar de forma eficiente sus servidores de producción y las apps que corren en ellos.

En los últimos dos años he pasado por tres stacks de monitorización distintos: primero Netdata, luego Grafana + Prometheus, y finalmente Beszel. Cada uno me enseñó algo, y he terminado en un sitio muy lejos de donde empecé. Si yo hubiera leído un post como este al principio, me habría ayudado un montón.

👉 Si tienes un puñado de VPS, un par de mini PCs, un NAS y quizá unos cuantos hosts con Docker, esto es para ti.

👉 Si tienes un equipo de 500 ingenieros, esto no es para ti. Vuelve a tus dashboards de Datadog.

Qué necesitaba yo realmente de la monitorización

Antes de meterme con las herramientas, déjame describir el problema, porque la respuesta correcta depende totalmente de lo que estés intentando hacer.

Ahora mismo tengo siete servidores en Hetzner (una mezcla de CX22 y CPX21), todos con Ubuntu, todos provisionados con Terraform, gestionados con Ansible, y la mayoría ejecutando contenedores Docker. Necesitaba:

1. CPU, memoria, disco y red por host, con un histórico de unas cuantas semanas.
2. Uso de recursos por contenedor (todo lo interesante vive en Docker).
3. Alertas cuando algo está ardiendo o a punto de arder. La parte más importante de la monitorización.
4. Un dashboard de visión general limpio que pueda mirar en cinco segundos cuando lo necesite.
5. Sobrecarga mínima del agente de recolección, para que no se coma los recursos del servidor.
6. Algo que con el tiempo pueda enseñar a clientes. Estoy construyendo RunMyApp, un servicio de self-hosting gestionado para pequeñas empresas en la UE, y “monitorizamos tu servidor de forma proactiva” es parte de mi propuesta de valor.

Lo que aún no está en esta lista: agregación de logs, distributed tracing, APM y observabilidad de nivel SRE. Los logs son lo único que todavía tengo pendiente de resolver. Así que si tienes alguna opción interesante, cuéntame.

Round 1: Netdata, un gran punto de partida

Netdata fue mi primera herramienta seria de monitorización y, sinceramente, está genuinamente bien. El agente se instala con un solo comando. El dashboard de Cloud es denso, bonito y útil, y muestra de todo: CPU, memoria, I/O de disco, red, todos los procesos en ejecución, todos los contenedores Docker, incluso las temperaturas por dispositivo.

Para los primeros tres o cuatro servidores, Netdata fue perfecto. Instalación de una sola línea. Los dashboards funcionan sin más. La lista de integraciones es enorme. PostgreSQL, Nginx, Redis, Traefik, lo que se te ocurra, hay un collector para ello. Configurar alertas vía webhook de Discord lleva diez minutos. Pero al final lo dejé por dos motivos.

Primero, el uso de recursos del agente. El agente de Netdata recoge una cantidad enorme de datos a alta resolución, lo cual es genial cuando lo necesitas, y notable cuando no. En mis VPS modestos, el agente podía tranquilamente comerse un pequeño porcentaje de CPU y entre 200 y 500 MB de RAM, dependiendo de lo que estuviera corriendo en el host y de lo que quisieras monitorizar. En una máquina de 4 GB con un par de servicios, eso es un peaje real.

Segundo, el precio. Netdata Cloud es gratis hasta 5 nodos. A partir de ahí, el tier Business sale a 4,50 USD por nodo al mes con facturación anual, lo que se traduce en 54 USD por nodo al año. Para una flota de siete nodos, son unos 378 USD al año. Para un presupuesto de homelab, es mucho.

Para ser justos, ahora tienen un tier Homelab a 90 USD al año para nodos ilimitados bajo una política de uso justo. Cuando hice el cambio esto todavía no existía, y es una oferta genuinamente justa si lo usas todo estrictamente para ti mismo. Pero hay dos cosas que aún me frenan. Primero, el tier Homelab prohíbe explícitamente el uso comercial en su política: “monitorizar la infraestructura de tu empresa”, “ofrecer servicios de monitorización a clientes”, “uso en un contexto empresarial”. RunMyApp encaja literalmente en ese cajón, así que para mí solo funciona el tier Business. Segundo, el dashboard vive en su nube, no en mi infraestructura, y yo prefiero ser dueño del stack completo.

Me sigue gustando mucho la plataforma, y creo que Netdata es un gran producto. Si tienes menos de cinco nodos, o encajas en el tier Homelab y no te importa un dashboard alojado en la nube, simplemente instala Netdata. De verdad va a cubrir todas tus necesidades, porque lo tiene todo. Pero si quieres todo self-hosted y un coste por nodo (casi) cero, sigue leyendo.

Round 2: Grafana + Prometheus, el clásico reconocido

La respuesta “real” en la comunidad de self-hosting es siempre Grafana + Prometheus. Es el stack de observabilidad open-source, el estándar de la industria, infinitamente flexible, y todos los empleadores del mundo quieren verlo en tu CV. ¿Cómo no intentar averiguar cómo va este cohete?

La configuración inicial, sinceramente, no fue tan terrorífica. Prometheus en Docker, node_exporter en cada host, cAdvisor para métricas de contenedores, Grafana como frontend, todo pegado con un par de ficheros docker-compose. Con un LLM a mano, tuve un stack funcionando en una tarde.

Luego intenté usarlo de verdad.

Y ahí empezó la diversión. Los dashboards de Grafana por defecto que importas de la galería de la comunidad quedan impresionantes en las capturas, pero te pierdes inmediatamente en ellos en cuanto empiezas a usarlos en la práctica. Sobre todo cuando tienes cero experiencia en este área (como yo).

La mitad de los paneles mostraban “No data” porque los nombres de las métricas en el dashboard no coincidían con lo que mi versión de node_exporter estaba exponiendo (ejemplo clásico: node_cpu de los dashboards antiguos frente a node_cpu_seconds_total de las versiones actuales). La otra mitad mostraba datos, pero con un diseño o estilo que no me funcionaba en absoluto.

Así que me puse a construir mi propio dashboard. Dios, eso es una forma de arte aparte a la que podrías dedicarle una vida entera. Para hacer un panel en Grafana que muestre algo útil, tienes que escribir PromQL. PromQL es un lenguaje de consulta bonito y potente, y no lo aprendes en una sola tarde. Pasé horas intentando expresar “uso medio de CPU por host en los últimos 5 minutos, excluyendo idle e iowait” sin que me devolviera cero o infinito. Al final conseguí algo que se parecía vagamente a la página de estado de Proxmox, y durante unos tres días estuve orgulloso del resultado.

Luego añadí un servidor nuevo.

Añadir un servidor implicaba volver a etiquetar, revisar las scrape configs, editar variables del dashboard y rehacer las queries de las plantillas para que el nuevo host apareciese en los desplegables. Quitar un servidor era todavía peor, porque los datos históricos se quedaban, y los dashboards mostraban huecos y fantasmas. Cada cambio de infraestructura se convertía en trabajo de dashboards. Quizá yo simplemente no sé hacerlo bien. Pero desde luego no es una solución rápida.

Sobre recursos: solo Prometheus se quedaba en idle alrededor de 300 MB de RAM en el host central de monitorización, y node_exporter + cAdvisor añadían otros 50 a 100 MB en cada host monitorizado. Con un par de semanas de histórico y siete nodos, el Prometheus central se acercaba a 600 u 800 MB. No es un desastre, pero tampoco es exactamente ligero. Quizá, otra vez, los pros saben hacer que use menos recursos del sistema. Pero yo no soy un pro. Y la verdad, ni siquiera tenía ganas de darle la lata a mi colega digital (la IA) con esto.

Lo dejé después de unas tres semanas. No porque el stack no funcionara, sino porque para mí el coste de mantenerlo estaba totalmente desproporcionado respecto al valor que me devolvía. Estaba dedicando más tiempo a afinar Grafana que a vigilar mi infraestructura de verdad.

Veredicto: Grafana + Prometheus es la respuesta correcta si (a) tienes una flota estable que cambia poco, (b) realmente necesitas dashboards y queries personalizados, (c) quieres aprender el stack por motivos profesionales, o (d) además necesitas agregación de logs (Loki) y quieres todo en un solo sitio. Para un homelab pequeño y en cambio constante donde solo quieres saber “¿está vivo el servidor?”, es brutalmente excesivo.

Round 3: Beszel, el “dónde has estado toda mi vida”

Me topé con una mención a Beszel en algún hilo de un foro de self-hosting, y al principio ni siquiera el nombre me inspiraba confianza. Pero luego lo instalé un buen domingo por la mañana, y a la hora de comer ya había migrado los siete servidores a la plataforma, y desde entonces vivo en ella. Tardé más en escribir este párrafo que en instalar Beszel.

Beszel es una herramienta ligera de monitorización de servidores self-hosted construida sobre PocketBase. Open source con licencia MIT, un único binario de Go más un agente diminuto, y hace exactamente lo que el 80% de los usuarios necesita de verdad de la monitorización: métricas del host, stats de contenedores Docker, gráficas históricas y alertas configurables. Nada de PromQL, nada de scrape configs en YAML, nada de hurgar en JSON de dashboards. El dashboard viene listo desde el primer momento y funciona sin más. Hay temas claro y oscuro. Y las alertas ya las mencioné, ¿verdad?

Los números hablan por sí solos. El Hub en sí usa unos 30 MB de RAM. El agente usa unos 10 MB por host. Compáralo con los 300 MB de Prometheus o los varios cientos de MB por agente de Netdata. En un VPS pequeño, esa es la diferencia entre “la monitorización es invisible” y “la monitorización es otro inquilino”.

Una nota arquitectónica importante: el Hub se conecta a los agentes (es un modelo pull sobre SSH), no al revés. Esto significa que en un host con agente, el puerto 45876 tiene que ser accesible para el Hub, y configuras tu firewall en consecuencia. A cambio, la clave pública del Hub vive en los agentes, y no se mueven tokens ni contraseñas en claro por la red.

Esto es lo que saco de él:

• Un dashboard estupendo que muestra todos los servidores a la vez, con información de CPU, memoria, disco y red.
• Pinchas en cualquier servidor y ves series temporales detalladas de los recursos más una lista de contenedores Docker con su uso de recursos.
• Alertas configurables globales o por servidor sobre CPU, memoria, disco, tráfico, temperatura y estado del host, enviadas a donde Shoutrrr soporte: Discord, Telegram, email, ntfy, Slack, los sospechosos habituales.
• Soporte multiusuario, para que puedas dar acceso de solo lectura a clientes.

Lo que más me gusta: cuando añado un servidor nuevo, ejecuto un solo comando en él, pego la clave en la UI del Hub, y el nuevo host aparece en el dashboard. Sin re-templating, sin re-labeling, sin PromQL. Cuando quito un servidor, lo borro del Hub y desaparece. El dashboard se adapta, porque el dashboard es el mismo para todos.

Qué cosas no hace Beszel

Quiero ser honesto sobre esto, porque es el motivo principal por el que Beszel no va a ser para todo el mundo.

Beszel no se ocupa de los logs. Monitoriza recursos. Si necesitas agregación, búsqueda y análisis centralizados de logs (Loki, el stack ELK, SigNoz, OpenObserve), Beszel no es tu herramienta. O corres algo en paralelo, o renuncias a la simplicidad y vuelves al stack de Grafana con Loki acoplado encima.

En mi caso, esto me vale. Rara vez necesito consultar logs entre hosts. Cuando lo hago, me conecto por SSH y lo hago a mano (bueno, con scripts que he ido construyendo con cuidado). Pero si estás ejecutando una app en producción y necesitas correlacionar errores entre servicios, Beszel por sí solo no te va a servir.

Qué más no hace Beszel: APM, distributed tracing, métricas personalizadas desde tus apps, checks sintéticos de endpoints externos, seguimiento de SLOs. Es, sin más, un monitor sencillo de recursos de host y contenedores. Ese foco es justo lo que lo hace tan bueno en lo que hace.

Comparativa rápida

La versión corta, así quedan los tres stacks lado a lado para mi escenario (7 nodos en Hetzner):

Los números de RAM son aproximados y dependen de tu configuración y retención. Pero el orden de magnitud ya cuenta la historia.

Una guía práctica para instalar Beszel

Ya que hemos llegado hasta aquí, así es como instalaría Beszel hoy. Asumiendo que tienes Docker y docker-compose en la máquina que va a ejecutar el Hub, y acceso SSH a las máquinas que quieres monitorizar.

Paso 1: Ejecuta el Hub

En la máquina que será tu Hub de monitorización, crea un directorio para Beszel y pon esto en un fichero docker-compose.yml:

services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel
    restart: unless-stopped
    ports:
      - "8090:8090"
    volumes:
      - ./beszel_data:/beszel_data

Arráncalo:

docker compose up -d

Abre http://tu-host:8090 en un navegador. Te pedirá crear el primer administrador.

Si quieres HTTPS (y lo quieres, sobre todo si lo expones a internet), pon Caddy o Traefik por delante. Caddy es lo más simple. Dos líneas en un Caddyfile son suficientes:

beszel.tudominio.com {
    reverse_proxy beszel:8090
}

Para que Caddy en un contenedor llegue a Beszel por el nombre beszel, ambos tienen que estar en la misma red Docker. O los arrancas en un mismo docker-compose, o les das una red externa a los dos y los conectas. Si Caddy está en el host en lugar de en un contenedor, sustituye beszel:8090 por localhost:8090. Caddy se encargará de pedir un certificado de Let’s Encrypt por su cuenta. Hub listo.

Paso 2: Añade un sistema

En la UI del Hub, pulsa “Add System”. Dale un nombre (yo uso hostnames mnemotécnicos, pero puede ser cualquier texto que te tenga sentido) y la IP o el hostname por el que el Hub pueda llegar al agente. Beszel muestra un diálogo con dos pestañas: Docker y Binary. En ambas, la clave pública del Hub y el token por sistema ya vienen rellenados; lo único que tienes que hacer es copiar el comando ya preparado.

Paso 3: Ejecuta el agente

Y aquí es donde se pone realmente bonito: Beszel ha hecho la instalación del agente tan sencilla que merece una grabación en vídeo. Planeo hacer una, por cierto, así que suscríbete a mi canal de YouTube para no perdértela.

Opción 1 (recomendada): un único script bash. En la pestaña Binary, pulsa “Copy Linux command” (o Homebrew/Windows/FreeBSD, lo que toque) y pégalo en el host que quieres monitorizar:

curl -sL https://get.beszel.dev -o /tmp/install-agent.sh && \
chmod +x /tmp/install-agent.sh && \
/tmp/install-agent.sh \
  -p 45876 \
  -k "ssh-ed25519 AAAAC3Nz... (la clave pública de tu Hub)" \
  -t "tu-token-del-sistema" \
  -url "https://tu-hub.ejemplo.com"

El script instala el binario, crea un servicio systemd, configura el token y la clave pública, y arranca el agente. Unos segundos después el sistema aparece en el Hub como “up” con métricas en vivo. Sin ficheros docker-compose, sin variables de entorno manuales.

Opción 2: Docker. Si vives en contenedores y no quieres un servicio systemd en el host, la pestaña Docker tiene botones ya preparados de “Copy docker compose” y “Copy docker run”. El contenido se parece más o menos a esto:

services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      LISTEN: 45876
      KEY: "ssh-ed25519 AAAA..."
      TOKEN: "tu-token-del-sistema"
      HUB_URL: "https://tu-hub.ejemplo.com"

Levántalo de la forma habitual con docker compose up -d.

Despliegue masivo con Ansible. Beszel soporta un token universal: un único token que puede registrar muchos agentes a la vez, con el Hub creando automáticamente los registros de sistema para ellos. Esto elimina el paso manual de “Add System” en la UI para cada host, y encaja perfectamente con Ansible. Guardo el token en Ansible Vault, lanzo una tarea shell sencilla en un playbook con el comando curl sobre un grupo de servidores, y la flota entera se registra sola.

Paso 4: Configura las alertas

En el Hub, abre la configuración de cada sistema y define los umbrales. CPU por encima del 80% durante 5 minutos, disco por encima del 90%, presión de memoria, host caído, lo que te importe. Añade los canales de notificación en la configuración de usuario, apúntalos a un webhook de Discord o a un bot de Telegram, y las alertas están vivas.

Paso 5: Haz backup

Beszel guarda todo en ./beszel_data (el volumen que montaste). Por debajo, eso es el SQLite de PocketBase, así que hay un detalle: hacer un tar de la base de datos en vivo bajo carga te puede dejar un snapshot corrupto. Dos opciones:

• Fácil: para el contenedor un minuto, hazle tar, vuelve a levantarlo. Vale para uso en homelab.
• Como toca: usa sqlite3 .backup para un snapshot atómico sin parar el servicio.

A partir de ahí es lo de siempre: un cron nocturno sube el archivo a S3, B2, o donde quiera que guardes tus backups. En mi setup va junto con el resto de mis datos de PocketBase.

Esa es la instalación entera. En serio. De cero a monitorizar una flota de siete servidores en menos de una hora si te lo tomas con calma.

Otras opciones que conviene conocer

No he probado personalmente muchas de estas, pero salen en cualquier conversación sobre monitorización, y he decidido juntar esta lista aquí para tu comodidad.

Uptime Kuma es una herramienta bonita y sencilla estilo página de estado para checks de uptime por HTTP/TCP/ping. Complementa a Beszel más que competir con él. Beszel te dice que el servidor está vivo y bien; Uptime Kuma te dice que tus servicios están respondiendo a peticiones públicas. Usa los dos si quieres.

SigNoz es una plataforma moderna de observabilidad construida sobre OpenTelemetry con soporte OTLP. Métricas, logs y trazas en un solo stack self-hosted, con un aire más moderno que Grafana + Loki + Tempo. Si necesitas logs y trazas y quieres una sola herramienta, yo miraría primero esta.

Zabbix es open source de nivel enterprise que lleva por aquí desde siempre. Muy potente, muy pesado, con una UI que parece diseñada en 2010. Vale la pena conocerlo, probablemente excesivo para un homelab.

Checkmk Raw es la versión gratuita de un producto comercial con genes Nagios. Una opción sólida para monitorización estilo sysadmin de entornos mixtos, pero la UX se siente anticuada.

Glances es una gran herramienta para un solo host, en CLI y web. Puede exportar a InfluxDB y Prometheus, así que no se limita estrictamente a un único host, pero aun así pierde frente a Beszel en UX para una flota. Si necesitas monitorizar exactamente una máquina y te encantan las terminales, Glances es una maravilla.

OpenObserve es una alternativa nueva y ligera a Elasticsearch/Loki para logs y métricas. No la he probado en serio, pero está en mi lista de “si alguna vez necesito logs”.

Cockpit es una herramienta web de administración de servidores de Red Hat con monitorización ligera integrada. Bien para administración de un solo host, no es realmente un dashboard multi-servidor.

El objetivo de esta lista no es ser exhaustivo sino darte un conjunto inicial de opciones de respaldo. Si Beszel no te encaja, alguna de estas probablemente sí. Puedes encontrar fácilmente reviews detalladas de cada una por internet.

Cómo elegir tu solución

Si quitas las marcas, la elección suele reducirse a cuatro preguntas:

1. ¿Cuántos hosts?
   • Menos de 5: Netdata gratis o Beszel.
   • De 5 a 50: Beszel, o Netdata Homelab si tus proyectos no son comerciales.
   • 50+: probablemente ya estás en territorio Prometheus o SigNoz.
2. ¿Necesitas logs? Si sí, mira Grafana + Loki, SigNoz u OpenObserve. Beszel no te va a ayudar. Si no, a Beszel es difícil ganarle.
3. ¿Cuánto tiempo tienes para setup y mantenimiento? Beszel: minutos. Netdata: minutos. El stack de Grafana: fines de semana, en plural.
4. ¿Es para ti o para clientes? Self-hosted te da la historia de confianza. En la nube te deja menos cosas que mantener.

Para mis necesidades actuales, Beszel es la respuesta correcta. Para las tuyas, quizá no, y no pasa nada. La conclusión real es esta: no te vayas por defecto a la herramienta más pesada solo porque es de la que más se habla. Encaja la herramienta con tu problema.

FAQ

¿Beszel está listo para producción? Para monitorización de recursos de host y contenedores, sí. Para observabilidad completa con logs, trazas y APM, no. Tienes que entender qué estás eligiendo.

¿Beszel soporta Windows? El agente compila para Linux, macOS y FreeBSD. Windows no es nativo; necesitas WSL2 o un contenedor. Para un homelab típico basado en Linux, esto no es un problema.

¿Puedo monitorizar Kubernetes? Beszel monitoriza hosts y contenedores Docker, no Pods como objetos de Kubernetes. Si usas k8s, necesitas kube-state-metrics más Prometheus o algo similar. Beszel no está pensado para eso.

¿En qué se diferencia Beszel de Uptime Kuma? Beszel monitoriza la salud del servidor desde dentro (CPU, RAM, disco, contenedores). Uptime Kuma monitoriza los servicios desde fuera (¿responde el endpoint HTTP?, ¿está abierto el puerto?). Resuelven problemas distintos y conviven felizmente uno al lado del otro.

¿Y las actualizaciones? ¿Se va a romper algo? Beszel es un proyecto joven y se desarrolla activamente. Salen releases con regularidad. Yo actualizo cada par de semanas con docker compose pull && docker compose up -d, y aún no se ha roto nada. Pero eso no es excusa para no hacer backup de la base de datos antes de actualizar.

Reflexiones finales

Pasé por Netdata, peleé con Grafana + Prometheus, y me quedé con Beszel. La lección no es que ninguna de estas herramientas sea mala. La lección es que “monitorización” abarca un rango amplio de tareas diarias, y cualquier respuesta popular probablemente apunta a problemas que la mayoría no tenemos en realidad.

Si tienes una flota pequeña de servidores y quieres saber qué está pasando, sin quemar fines de semana en PromQL ni pagar por cada nodo todos los meses, instala Beszel esta tarde. En el peor caso pierdes veinte minutos. En el mejor, terminas con una monitorización que realmente vas a usar durante años.

Y si acabas usándola, el proyecto Beszel es trabajo open source de una sola persona que se ha convertido en algo brillante. Dale una estrella al repo, abre buenos reportes de bugs, y si puedes, apoya al mantenedor. El ecosistema self-hosted vive de gente así.

Y si prefieres no lidiar con despliegues, actualizaciones y monitorización en absoluto, ese es exactamente el caso para el que estoy construyendo RunMyApp: tus apps en tu servidor, y nosotros vigilándolo. Si te interesa, escríbeme.

Espero que este post te haya ayudado a orientarte. Si quieres enterarte de los nuevos posts, suscríbete a las notificaciones. No hago spam, porque a mí tampoco me gusta el spam.

Suerte.