[{"data":1,"prerenderedAt":188},["ShallowReactive",2],{"seo-verification":3,"blog-monitorizacion-proactiva-vps-beszel-uptime-kuma-v2-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-monitorizacion-proactiva-vps-beszel-uptime-kuma-v2-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":130,"ctaBody":131,"ctaButton":132,"ctaUrl":133,"relatedPosts":134},440,"monitorizacion-proactiva-vps-beszel-uptime-kuma-v2",{"fr":12,"en":13,"ar":14,"es":10},"monitoring-alerte-proactif-self-hosted-vps","proactive-vps-monitoring-beszel-uptime-kuma-v2","مراقبة-استباقية-vps-beszel-uptime-kuma","Monitorización proactiva en VPS: Beszel y Uptime Kuma v2","Despliega Beszel y Uptime Kuma v2 en un VPS para supervisar toda tu flota de servidores y recibir alertas por Telegram o SMTP antes de que tus clientes detecten la caída.",11,0,false,"2026-10-14T00:00:00+00:00","2026-10-14T23:33:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fmonitoring-alerte-proactif-self-hosted-vps-poster.svg","Un servicio PostgreSQL se detiene sin disparar ninguna alerta de disco. El cliente llama. Te enteras del corte al mismo tiempo que él. Este caso, documentado y compartido en la comunidad en octubre de 2026, ilustra el problema de las pilas de monitorización de una sola capa: cada herramienta ve solo lo que observa, y nada más. La combinación de Beszel con Uptime Kuma v2 cubre ambos ángulos — métricas del sistema en cada host, y verificación de disponibilidad de extremo a extremo — con un coste en recursos inferior al de un WordPress inactivo.",[35,39,51,54,79,82,120,124,127],{"type":36,"title":37,"body":38},"h2","Por qué la monitorización proactiva, y por qué las herramientas clásicas no son suficientes","La alerta reactiva — la que llega después de que el cliente ya ha llamado — no protege la relación. La repara. La diferencia entre ambos no es cuestión de suerte: es cuestión de cobertura.\n\nUna herramienta de monitorización de disponibilidad como Uptime Kuma comprueba que un servicio responde en un puerto o URL. No sabe si PostgreSQL está funcionando fuera de ese puerto, si la memoria del contenedor está a punto de saturarse, o si el disco de logs se llena a 200 MB por hora. Por el contrario, una herramienta de métricas del sistema como Beszel monitoriza continuamente el consumo de recursos de cada host, pero no prueba los servicios de aplicación de extremo a extremo.\n\nEl caso documentado en \u003Ca href=\"https:\u002F\u002Flemmy.world\u002Fpost\u002F52895878\">Lemmy\u003C\u002Fa> el 11 de octubre de 2026 (112 votos) ilustra exactamente esto: PostgreSQL se había detenido en un VPS sin disparar ninguna alerta de disco. No se había superado ningún umbral de espacio. Solo una verificación a nivel de aplicación habría detectado la parada — algo que el operador no tenía implementado.\n\nLa pila Beszel + Uptime Kuma v2 aborda ambos ángulos. Beszel monitoriza las métricas de cada host (CPU, RAM, disco, red, contenedores) desde un hub central. Uptime Kuma v2 verifica la disponibilidad de los servicios expuestos con canales de alerta configurables. Ambos son de código abierto, auto-alojados, y se instalan en un VPS dedicado a supervisar tu flota.",{"type":40,"title":41,"items":42},"ul","Lo que esta pila aporta concretamente a una agencia",[43,44,45,46,47,48,49,50],"Vista unificada de todos los servidores de tus clientes en una sola interfaz Beszel, sin multiplicar los accesos SSH.","Alertas de métricas (CPU, RAM, disco, red) con umbrales configurables por host.","Verificaciones de disponibilidad HTTP(s), TCP, DNS y certificados SSL vía Uptime Kuma v2 — cada 60 segundos por defecto.","Notificaciones por Telegram o SMTP operativas en la primera hora, sin suscripción a servicios externos.","Detección de saturación de disco o fuga de memoria antes de que bloquee un servicio de aplicación.","Páginas de estado públicas de Uptime Kuma compartibles con los clientes finales.","Consumo total de la pila inferior a 150 MB de RAM en el VPS de supervisión.","Despliegue reproducible mediante Docker Compose, versionable y redesplegable en minutos.",{"type":36,"title":52,"body":53},"Requisitos de recursos","Para alojar el hub Beszel y Uptime Kuma v2 en un VPS dedicado a la supervisión:\n\n**Recursos mínimos.** Un VPS de 1 vCPU con 1 GB de RAM es suficiente para supervisar alrededor de diez hosts con Beszel y unos cincuenta monitores con Uptime Kuma. En la práctica, Beszel hub consume alrededor de 50 MB de RAM y Uptime Kuma v2 alrededor de 100 MB — menos de 200 MB en total en reposo, según mediciones de la comunidad. Para una flota de 20 a 50 VPS, planifica 2 GB de RAM. Beszel almacena sus datos en SQLite; reserva 5 a 10 GB de disco para conservar varios meses de historial.\n\n**Software necesario.** Docker y Docker Compose instalados en el VPS de supervisión. Un dominio o subdominio apuntando a este VPS (`monitoring.your-domain.com`) para el proxy inverso y SSL. Los puertos 80 y 443 abiertos para el proxy inverso, y el puerto `8090` o cualquier puerto de tu elección para el hub Beszel.\n\n**En los VPS supervisados.** Cada host a supervisar recibe únicamente el agente Beszel — un binario ligero o contenedor Docker que consume unos 10 MB de RAM. No se requieren cambios en el firewall público: el agente inicia la conexión hacia el hub, no al revés.",{"type":55,"title":56,"steps":57},"steps","Despliegue completo: hub Beszel, agentes, Uptime Kuma v2 y alertas",[58,61,64,67,70,73,76],{"title":59,"body":60},"Crear la estructura Docker Compose en el VPS de supervisión","Conéctate al VPS dedicado a la supervisión. Crea un directorio de trabajo y el archivo Compose:\n\n```bash\nmkdir -p \u002Fopt\u002Fmonitoring && cd \u002Fopt\u002Fmonitoring\n```\n\nCrea `docker-compose.yml` con los dos servicios:\n\n```yaml\nservices:\n  beszel:\n    image: henrygd\u002Fbeszel:latest\n    restart: unless-stopped\n    volumes:\n      - .\u002Fbeszel_data:\u002Fbeszel_data\n    ports:\n      - \"8090:8090\"\n    environment:\n      - DATA_DIR=\u002Fbeszel_data\n\n  uptime-kuma:\n    image: louislam\u002Fuptime-kuma:2\n    restart: unless-stopped\n    volumes:\n      - .\u002Fuptime-kuma-data:\u002Fapp\u002Fdata\n    ports:\n      - \"3001:3001\"\n    healthcheck:\n      test: [\"CMD\", \"node\", \"extra\u002Fhealthcheck\"]\n      interval: 30s\n      timeout: 10s\n      retries: 3\n```\n\nObserva el bloque `healthcheck` en Uptime Kuma: es indispensable para evitar el problema del crash-loop (ver sección Trampas).",{"title":62,"body":63},"Arrancar la pila y crear las cuentas de administrador","Lanza los dos contenedores:\n\n```bash\ndocker compose up -d\n```\n\nVerifica que ambos contenedores estén en estado `healthy` o `running`:\n\n```bash\ndocker compose ps\n```\n\nAccede a Beszel en `http:\u002F\u002F\u003Cip-vps>:8090` y crea la cuenta de administrador en el primer acceso. Haz lo mismo con Uptime Kuma en `http:\u002F\u002F\u003Cip-vps>:3001`. Ambas interfaces deben colocarse después detrás de un proxy inverso con SSL para no exponerlas en HTTP plano.",{"title":65,"body":66},"Desplegar el agente Beszel en cada VPS a supervisar","En cada VPS cliente a supervisar, copia la clave pública generada en la interfaz de Beszel (Configuración → Clave SSH) y ejecuta:\n\n```bash\ncurl -sL https:\u002F\u002Fraw.githubusercontent.com\u002Fhenrygd\u002Fbeszel\u002Fmain\u002Fsupplemental\u002Fscripts\u002Finstall-agent.sh | bash -s -- -p 45876 -k \"\u003Ctu-clave-publica>\"\n```\n\nAlternativamente, usa Docker en el host supervisado:\n\n```yaml\nservices:\n  beszel-agent:\n    image: henrygd\u002Fbeszel-agent:latest\n    restart: unless-stopped\n    network_mode: host\n    volumes:\n      - \u002Fvar\u002Frun\u002Fdocker.sock:\u002Fvar\u002Frun\u002Fdocker.sock:ro\n    environment:\n      - KEY=\u003Ctu-clave-publica>\n      - PORT=45876\n```\n\nEn Beszel, añade cada host desde la interfaz (Sistemas → Añadir sistema) indicando su IP y el puerto del agente. La conexión la establece el hub hacia el agente: el host supervisado no necesita exponer ese puerto públicamente.",{"title":68,"body":69},"Configurar las alertas de métricas en Beszel","En Beszel, abre el detalle de un sistema y ve a la pestaña Alertas. Configura umbrales en las métricas críticas:\n\n- **Disco**: alerta al 80% y crítica al 90% — cubre el caso PostgreSQL del escenario inicial.\n- **RAM**: alerta si el uso supera el 85% sostenido durante 5 minutos.\n- **CPU**: alerta si la carga supera el 90% durante más de 3 minutos.\n\nBeszel soporta Telegram, Discord, Slack, Gotify, Ntfy y webhooks genéricos. Para Telegram necesitas un token de bot (obtenido desde `@BotFather`) y el ID de tu chat o grupo.",{"title":71,"body":72},"Configurar los monitores Uptime Kuma v2 y las alertas SMTP o Telegram","En Uptime Kuma, comienza configurando un canal de notificación (Configuración → Notificaciones). Dos opciones habituales:\n\n**Telegram.** Introduce el token del bot y el ID del chat. El mismo bot que para Beszel funciona — usa un solo bot para ambas herramientas y distingue con canales diferentes.\n\n**SMTP.** Introduce el servidor SMTP, el puerto (587 con STARTTLS), las credenciales y la dirección de destino. Usa una cuenta dedicada al envío de alertas.\n\nCrea después los monitores para cada servicio crítico: URL HTTP(s) para los sitios web, TCP para bases de datos y puertos de aplicación. Para el caso PostgreSQL, añade un monitor TCP en el puerto `5432` de cada VPS que aloje una instancia — si PostgreSQL se detiene, el puerto deja de responder y la alerta se dispara en segundos.",{"title":74,"body":75},"Poner todo detrás de un proxy inverso con SSL","Añade un servicio nginx o Caddy al Compose para exponer Beszel y Uptime Kuma por HTTPS:\n\n```yaml\n  caddy:\n    image: caddy:alpine\n    restart: unless-stopped\n    ports:\n      - \"80:80\"\n      - \"443:443\"\n    volumes:\n      - .\u002FCaddyfile:\u002Fetc\u002Fcaddy\u002FCaddyfile\n      - caddy_data:\u002Fdata\n```\n\nCon un `Caddyfile` mínimo:\n\n```\nmonitoring.your-domain.com {\n    reverse_proxy beszel:8090\n}\n\nstatus.your-domain.com {\n    reverse_proxy uptime-kuma:3001\n}\n```\n\nCaddy emite y renueva automáticamente los certificados Let's Encrypt. Elimina las secciones `ports` de beszel y uptime-kuma en el Compose en cuanto estén proxificados — no deben ser accesibles directamente.",{"title":77,"body":78},"Verificar el funcionamiento y configurar la retención","Prueba todo deteniendo manualmente un servicio en un VPS de prueba (`docker compose stop \u003Cservicio>`) y verificando que la alerta de Telegram o SMTP llega en menos de dos minutos.\n\nPara Beszel, configura la retención de datos en Configuración → Retención: el valor por defecto es 7 días para datos de alta resolución y 30 días para agregados por hora. Ajusta según la capacidad de tu disco.\n\nPara Uptime Kuma, la retención se configura en Configuración → Avanzado → Limpieza automática. Conserva al menos 90 días para tener tendencias mensuales de uptime que presentar a los clientes.",{"type":36,"title":80,"body":81},"Trampas a conocer antes de pasar a producción","**El crash-loop de Docker declarado como UP — issue de Uptime Kuma #7956.** Sin `healthcheck` en el Compose, Docker puede reportar un contenedor de Uptime Kuma como `running` mientras está en un bucle de reinicios. El monitor de Uptime Kuma que se vigila a sí mismo (TCP en el puerto 3001) mostraría un falso positivo: el puerto responde durante el breve intervalo entre dos reinicios. La solución es exactamente el bloque `healthcheck` mostrado en el paso 1 — usa el script incluido en la imagen para probar el estado interno de la aplicación, no solo la presencia del proceso. Docker pasa entonces el contenedor a `unhealthy` si el check falla tres veces seguidas, y el monitor de Uptime Kuma lo detecta.\n\n**El agente Beszel con `network_mode: host`.** Si los hosts supervisados ejecutan contenedores, el agente Beszel necesita acceso al socket de Docker (`\u002Fvar\u002Frun\u002Fdocker.sock`) para reportar métricas por contenedor. En modo de red bridge el socket es accesible pero la IP reportada por el agente puede ser la de la red Docker interna. Prefiere `network_mode: host` en el agente para garantizar que el hub Beszel ve la IP pública del servidor.\n\n**Las alertas de Beszel no reemplazan las verificaciones a nivel de aplicación.** Beszel monitoriza los recursos del sistema y la disponibilidad de los contenedores Docker. No prueba que una aplicación responde correctamente a una petición HTTP o que PostgreSQL acepta conexiones. Estos dos niveles son complementarios: Beszel detecta la saturación que precede al fallo, Uptime Kuma confirma el fallo cuando ocurre.",{"type":83,"title":84,"headers":85,"rows":90},"comparison","Cobertura de alertas según la configuración de la pila",[86,87,88,89],"Escenario de fallo","Solo Beszel","Solo Uptime Kuma","Beszel + Uptime Kuma v2",[91,96,101,106,110,115],[92,93,94,95],"Disco lleno al 95%","Alerta en el umbral configurado","No detectado","Alerta Beszel antes del fallo",[97,98,99,100],"PostgreSQL detenido (puerto TCP caído)","No detectado (servicio fuera de Docker)","Alerta TCP en \u003C 2 min","Alerta TCP de Uptime Kuma",[102,103,104,105],"Contenedor en crash-loop","Alerta si afecta a CPU\u002FRAM","Falso positivo sin healthcheck","Detectado si healthcheck implementado",[107,108,94,109],"Fuga de memoria progresiva","Alerta en umbral de RAM","Alerta anticipatoria de Beszel",[111,112,113,114],"Certificado SSL expirando en 7 días","No monitorizado","Alerta de expiración SSL","Alerta SSL de Uptime Kuma",[116,117,118,119],"VPS inaccesible (red o host caído)","Hub pierde el agente","Alerta TCP\u002FHTTP","Señal doble, convergente",{"type":121,"title":122,"body":123},"tip","Bastionado: aísla el VPS de supervisión","El VPS de supervisión es un activo crítico: si cae, pierdes visibilidad sobre todo lo demás. Tres reglas para bastionarlo.\n\nPrimero, no albergues aplicaciones de clientes en este VPS. Su carga debe ser predecible y su único rol es la supervisión.\n\nSegundo, cierra todos los puertos innecesarios con el firewall del VPS. Solo 80, 443 y el puerto SSH (movido a un puerto no estándar) deben ser accesibles desde Internet. El puerto del agente Beszel (45876 por defecto) solo debe estar abierto desde las IPs de tus otros VPS, no desde toda Internet.\n\nTercero, añade un monitor externo de Uptime Kuma — por ejemplo desde un servicio de check HTTP gratuito — que verifique que tu propia instancia de Uptime Kuma responde. Sin esta capa externa, un fallo del propio VPS de supervisión pasa desapercibido.",{"type":36,"title":125,"body":126},"Solución de problemas habituales","**El agente Beszel aparece desconectado inmediatamente después de añadirlo.** Verifica que el puerto del agente (45876 por defecto) sea alcanzable desde el hub. En el host supervisado, prueba con `nc -zv \u003Cip-hub> 8090` — si la conexión falla, el problema está en el firewall del hub. El propio agente no requiere ningún puerto de entrada abierto.\n\n**Uptime Kuma no recibe las alertas de Telegram.** El motivo más frecuente es una desviación de reloj en el contenedor. Comprueba con `docker exec uptime-kuma date` que la hora coincide con la UTC real. Si no es así, añade `\u002Fetc\u002Flocaltime:\u002Fetc\u002Flocaltime:ro` en los volúmenes del servicio Uptime Kuma.\n\n**El hub Beszel no arranca o pierde datos tras un reinicio.** Verifica que el volumen `.\u002Fbeszel_data` pertenece al UID usado por el contenedor Beszel. Un error de permisos en el directorio de datos impide que SQLite escriba: `chown -R 1000:1000 .\u002Fbeszel_data` resuelve el problema en la mayoría de los casos.\n\n**Uptime Kuma en estado `unhealthy` al arrancar.** La imagen v2 puede tardar de 30 a 60 segundos en arrancar completamente antes de que el healthcheck pase. Es normal. Si el contenedor sigue en `unhealthy` después de dos minutos, consulta los logs: `docker compose logs uptime-kuma`.",{"type":36,"title":128,"body":129},"Para ir más lejos","Esta pila cubre los dos niveles esenciales: métricas del sistema y verificación de disponibilidad. Para un tercer nivel — trazabilidad y análisis fino de tendencias de carga — la pila Grafana + Prometheus es el siguiente paso natural. Es más intensiva en recursos (planifica 2 GB de RAM dedicados), pero abre PromQL y los dashboards a medida. El artículo \u003Ca href=\"\u002Fblog\u002Fmonitoring-vps-grafana-prometheus\">Monitorización de VPS con Grafana y Prometheus\u003C\u002Fa> cubre ese despliegue paso a paso.\n\nPara las copias de seguridad del propio VPS de supervisión — y evitar reconstruir toda la configuración en caso de pérdida — \u003Ca href=\"\u002Fblog\u002Fbackup-vps-restic-s3-3-2-1\">la estrategia 3-2-1 con Restic y almacenamiento S3\u003C\u002Fa> se aplica directamente a los volúmenes Docker de esta pila.\n\nSi gestionas varios servidores de clientes desde una sola plataforma, la página \u003Ca href=\"\u002Fsolutions\u002Fagences\">\u002Fsolutions\u002Fagences\u003C\u002Fa> detalla cómo ServOrbit centraliza la supervisión de tu flota en un VPS Start.","Supervisa tu flota desde un único VPS","Gestionas varios servidores de clientes. Centraliza la supervisión de tu flota en un VPS ServOrbit con acceso root, IPv4 dedicada y Docker — la pila Beszel + Uptime Kuma v2 funciona en el plan de entrada.","Supervisar mi flota","\u002Fsolutions\u002Fagences",[135,154,171],{"id":136,"slug":137,"slugs":138,"title":142,"excerpt":143,"readTime":144,"views":18,"isPinned":19,"publishedAt":145,"updatedAt":146,"category":147,"categories":148,"featuredImage":30,"bgImage":31,"posterImage":150,"relatedSolution":151},105,"supervisar-vps-con-uptime-kuma",{"fr":139,"en":140,"ar":141,"es":137},"superviser-vps-uptime-kuma","monitoring-your-vps-with-uptime-kuma","مراقبة-خادمك-الافتراضي-vps-باستخدام-uptime-kuma","Supervisar su VPS con Uptime Kuma","Despliegue Uptime Kuma en su VPS para supervisar sus sitios y servicios en self-hosted, con alertas y página de estado pública.",4,"2026-03-07T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[149],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsuperviser-vps-uptime-kuma-poster.svg",{"categorySlug":152,"appSlug":153},"monitorizacion-observabilidad","uptime-kuma",{"id":155,"slug":156,"slugs":157,"title":161,"excerpt":162,"readTime":23,"views":163,"isPinned":19,"publishedAt":164,"updatedAt":146,"category":165,"categories":166,"featuredImage":30,"bgImage":31,"posterImage":168,"relatedSolution":169},133,"alojar-beszel-hub-monitorizacion-vps",{"fr":158,"en":159,"ar":160,"es":156},"self-host-beszel-vps","self-host-beszel-multi-server-monitoring-hub-on-your-vps","استضف-beszel-على-vps-مركز-مراقبة-متعدد-الخوادم","Beszel en VPS: monitorización multiservidor, alertas y seguridad","Supervise su parque de VPS desde un único hub Beszel: alertas por Telegram y correo, 2FA, agentes declarados automáticamente y solución de conexiones silenciosas.",1,"2026-02-14T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[167],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fself-host-beszel-vps-poster.svg",{"categorySlug":152,"appSlug":170},"beszel",{"id":172,"slug":173,"slugs":174,"title":178,"excerpt":179,"readTime":17,"views":18,"isPinned":19,"publishedAt":180,"updatedAt":181,"category":182,"categories":183,"featuredImage":30,"bgImage":31,"posterImage":185,"relatedSolution":186},106,"monitorizacion-vps-grafana-prometheus",{"fr":175,"en":176,"ar":177,"es":173},"monitoring-vps-grafana-prometheus","vps-monitoring-with-grafana-and-prometheus","مراقبة-الخادم-الافتراضي-vps-باستخدام-grafana-و-prometheus","Monitorización de VPS con Grafana y Prometheus","Despliegue Prometheus 3.x, Grafana 13.x, Node Exporter y Alertmanager en su VPS con Docker Compose. Paneles, alertas y bastionado.","2026-03-06T00:00:00+00:00","2026-10-05T14:05:27+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[184],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fmonitoring-vps-grafana-prometheus-poster.svg",{"categorySlug":152,"appSlug":187},"grafana",1792032019070]