Glances — monitoreo centralizado

Panel de monitoreo centralizado de los servidores de Esteban. El hub corre en Docker (network_mode: host) en vm-playground, expuesto públicamente en monitor.estebanalcocer.cloud mediante un túnel de Cloudflare, y conectado a sus agentes remotos mediante NetBird. El hub se instaló en vm-playground en vez de en vm-main porque vm-playground es el host que tiene el túnel de Cloudflare para la zona estebanalcocer.cloud — el túnel de vm-main solo tiene permiso sobre la zona conkafecito.com, cuenta distinta.

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.124.160.191, agente instalado y conectado.
• vm-backup — IP NetBird 100.124.26.69, agente instalado y conectado.
• vm-playground — IP NetBird 100.124.53.166, agente instalado y conectado (host del propio hub).
• vm-personal — IP NetBird 100.124.197.130 ya asignada, pero sin agente instalado todavía.
• 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, mismo patrón de Docker + túnel de Cloudflare
• Trilium — ídem