Glances — monitoreo centralizado

Panel de monitoreo centralizado de los servidores de Esteban. El hub corre en Docker (network_mode: host) en vm-main (movido desde vm-playground el 2026-08-10, rediseño vm-producción/vm-workstation — ver hosts.md), expuesto públicamente en monitor.estebanalcocer.cloud mediante un túnel de Cloudflare, y conectado a sus agentes remotos mediante NetBird. Originalmente el hub se instaló en vm-playground porque en ese momento era el único host con túnel de Cloudflare para la zona estebanalcocer.cloud — motivo ya obsoleto desde el 2026-08-05 (vm-main tiene su propio túnel para esa zona), y por eso pudo mudarse sin fricción de zona/cuenta.

Arquitectura

Cada host que se monitorea corre un agente de Glances bindeado a su propia IP de NetBird; el hub del panel los consulta vía REST sobre la malla de NetBird.

Decisión de diseño explícita: todos los agentes se monitorean por su IP de NetBird, nunca por IP privada de VCN ni abriendo puertos en el firewall de la nube. Motivo: es más simple, no depende de tocar la consola de OCI, y NetBird ya estaba desplegado en casi todos los hosts de todos modos.

Instalar un agente nuevo

1. Si el host no tiene NetBird: curl -fsSL https://pkgs.netbird.io/install.sh | sudo sh y sudo netbird up --setup-key <KEY> (setup key de un solo uso, se genera en app.netbird.io/peers → “Add Peer”).
2. Obtener la IP asignada: netbird status | grep "NetBird IP".
3. Editar el flag -B <ip> de ExecStart en /etc/systemd/system/glances-agent.service con esa IP, luego systemctl daemon-reload && systemctl restart glances-agent.
4. Reflejar la IP en el server_N_name correspondiente de glances.conf (en el hub) y docker compose restart ahí.

Datos técnicos clave

• Instalar Glances siempre vía pipx install "glances[web]" — nunca el paquete de apt (versión vieja, protocolo/API incompatible con v4). El extra [web] es obligatorio: sin él falta fastapi y el modo -w no arranca.
• Comando del hub: glances --browser -w. Solo --browser es un TUI de terminal, no sirve para exponer vía navegador.
• Puerto de agente: 61208 en todos los hosts, modo REST (server_N_protocol=rest) — no se usa el modo -s/rpc (puerto 61209) en ningún host, para mantenerlo homogéneo.
• network_mode: host es obligatorio en el docker-compose.yml del hub — ver Docker para el motivo (hairpin NAT). Con el bridge por defecto, el contenedor alcanzaba las IPs NetBird de otros hosts pero no la del propio.
• Glances 4.5.x tiene una opción webui_allowed_hosts (sección [outputs]) para restringir el Host header aceptado (protección DNS-rebinding); en 4.5.5 no se aplica por defecto, así que no bloquea nada hoy, pero es hardening recomendado antes de agregar autenticación al panel.

Estado de los agentes

• vm-main — IP NetBird 100.71.231.234, agente instalado y conectado (host del propio hub).
• vm-playground — IP NetBird 100.71.230.199, agente instalado y conectado (ya no es el host del hub, pero conserva su propio agente sin cambios).
• vm-personal — IP NetBird 100.71.92.49 ya asignada, pero sin agente instalado todavía.

IPs actualizadas el 2026-08-09 por la migración de cuenta de NetBird (detalle) — el -B <ip> de glances-agent.service en los tres hosts (entonces vm-main, vm-backup, vm-playground) y los server_N_name de glances.conf en el hub se corrigieron a mano en la misma sesión; de otro modo el bind se queda sordo en la IP vieja sin que el systemctl status lo delate (sigue en active). vm-backup se decomisionó el 2026-08-10 — su entrada ya se sacó de glances.conf y el hub confirma solo 2 servidores (ONLINE ambos) tras el docker compose restart.

• vm-ubuntu (on-premise, Conkafecito) y sr250 — no forman parte del hub. vm-ubuntu no tiene NetBird ni una ruta SSH confirmada desde vm-personal. sr250 tiene un peer NetBird conectado (eri-sr250) pero no se confirmó que corresponda a la misma máquina física, y llegar por SSH ahí requiere login interactivo por navegador vía Cloudflare Access.

Los agentes de vm-main y vm-backup se instalaron usando acceso SSH entre VMs vía vm-personal como jump host, porque vm-playground no tiene credenciales SSH propias hacia esas dos VMs.

Seguridad

El sitio queda público sin autenticación por decisión explícita de Esteban (“ahorita sin seguridad, ya después vemos”). Falta agregar Cloudflare Access u otra protección delante del hostname.

Véase también

• Docker — por qué network_mode: host es obligatorio en este contenedor
• Túneles de Cloudflare — cómo se expone monitor.estebanalcocer.cloud
• NetBird — la malla que conecta el hub con sus agentes
• Acceso SSH entre VMs — cómo se llegó a vm-main/vm-backup para instalar los agentes
• Wasquedul — mismo host desde el 2026-08-10, mismo patrón de Docker
• Trilium — decomisionado el 2026-08-10, ya no comparte host con este hub