Cómo monitorizar tu servidor con Glances en Docker
Índice de contenidos
- Puntos clave
- ¿Qué es Glances y qué monitoriza?
- ¿Cómo es el docker-compose.yml de Glances?
- ¿Qué métricas de sistema y de contenedores muestra?
- ¿Cómo usar el modo cliente/servidor y la API REST?
- ¿Glances o Netdata: cuál elegir?
- Preguntas frecuentes
- ¿Por qué Glances no ve mis contenedores ni los procesos del host?
- ¿Debo usar la etiqueta latest de Glances?
- ¿Cuántos recursos consume Glances?
- Conclusión
- Fuentes
Glances es un monitor de sistema en tiempo real escrito en Python que, en modo web server, muestra CPU, memoria, disco, red y contenedores desde el navegador en el puerto 61208. Con Docker lo levantas con un solo docker-compose.yml, montando el socket de Docker, y además expone una API REST en /api/4 para automatizar.
Glances te da una foto completa de tu servidor de un vistazo, y con Docker lo tienes vigilando CPU, memoria, disco, red y contenedores en un par de minutos. En esta guía levantas Glances en modo web server con un solo archivo docker-compose.yml, entiendes qué métricas de sistema y de contenedores muestra, expones su API REST para automatizar y decides cuándo te compensa frente a Netdata. La misma explicación está disponible en inglés.
Puntos clave
- Glances es un monitor de sistema multiplataforma escrito en Python por Nicolas Hennion (nicolargo) en 2011; se apoya en la librería
psutily funciona como una alternativa atopyhtopcon interfaz web y API. - La última versión estable es Glances 4.5.5, publicada el 13 de junio de 2026; fija ese tag en lugar de
:latestpara no llevarte sorpresas al actualizar. - En modo web server la interfaz vive en el puerto 61208; el modo cliente/servidor (XML-RPC) usa el 61209, y ambos se publican juntos.
- Glances expone una API REST en
/api/4(por ejemplohttp://localhost:61208/api/4/cpu), lo que te permite alimentar paneles como Homepage o scripts de alerta. - Para ver los contenedores necesitas montar
/var/run/docker.socken modo solo lectura; para los procesos y la memoria reales del host, arrancar conpid: host.
¿Qué es Glances y qué monitoriza?
Glances es una herramienta de monitorización de sistema en tiempo real que reúne en una sola pantalla lo que normalmente mirarías con varios comandos distintos: uso de CPU por núcleo, memoria y swap, carga del sistema, entrada y salida de disco, tráfico de red, sensores de temperatura, procesos que más consumen y, si le das acceso al socket, el estado de tus contenedores Docker. Está escrito en Python y recoge los datos a través de la librería psutil, la misma que usan muchas herramientas de observabilidad del ecosistema.
Su gracia es la densidad de información sin configuración: arrancas el contenedor y ya tienes un cuadro completo, con colores que pasan de verde a rojo según el umbral de cada métrica. Puedes usarlo de tres formas: en consola (como un htop con esteroides), en modo web server para verlo desde el navegador y en modo cliente/servidor para consultar una máquina remota. Como resume su documentación, Glances es "un top/htop alternativo" pensado para vigilar un sistema entero de un solo golpe de vista. Para el contexto de qué son los límites de recursos y los logs que aquí verás reflejados, tienes la guía sobre límites de recursos y logs en Docker.
¿Cómo es el docker-compose.yml de Glances?
La imagen oficial es nicolargo/glances en Docker Hub, con variantes de tag: el sufijo -full añade las dependencias opcionales (sensores, GPU, exportadores), así que para un servidor casero conviene el tag completo y con versión fija. Este docker-compose.yml arranca Glances en modo web server, monta el socket de Docker en solo lectura para ver los contenedores y usa pid: host para que las métricas de procesos sean las del anfitrión y no las del contenedor:
services:
glances:
image: nicolargo/glances:4.5.5-full
restart: unless-stopped
pid: host
environment:
GLANCES_OPT: "-w"
ports:
- "61208:61208"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- /etc/os-release:/etc/os-release:ro
healthcheck:
test: ["CMD-SHELL", "python3 -c \"import urllib.request; urllib.request.urlopen('http://localhost:61208/')\" || exit 1"]
interval: 30s
timeout: 10s
retries: 3
Merece la pena detenerse en tres detalles. La variable GLANCES_OPT: "-w" es la que activa el modo web server; sin ella el contenedor arranca en consola y no sirve la interfaz. El montaje /var/run/docker.sock:...:ro da a Glances acceso de solo lectura a la API de Docker para listar los contenedores y su consumo, sin permitir que los controle. Y pid: host comparte el espacio de procesos del anfitrión, de modo que la pestaña de procesos muestra lo que de verdad corre en la máquina. El healthcheck usa el propio Python de la imagen para comprobar que la web responde, evitando depender de que curl o wget estén instalados.
Con el archivo en su sitio, arranca la pila y comprueba el estado:
docker compose up -d
docker compose ps
docker compose logs -f glances
Abre http://localhost:61208 en el navegador y verás el panel de Glances actualizándose solo. El refresco por defecto es de 1 segundo; puedes cambiarlo añadiendo el intervalo a la URL, por ejemplo http://localhost:61208/5 para refrescar cada 5 segundos y aliviar la carga.
¿Qué métricas de sistema y de contenedores muestra?
El panel se organiza por bloques. Arriba tienes el resumen de CPU, memoria, swap y carga; a la izquierda, la red, la entrada y salida de disco, los sistemas de archivos y los sensores; y en el cuerpo central, la lista de procesos ordenada por consumo, igual que en htop. Cada valor cambia de color al superar un umbral (por defecto, cuidado a partir del 70 % y crítico a partir del 90 %), así que un rojo salta a la vista sin tener que leer cifras.
Como le has dado acceso al socket de Docker, Glances añade una sección de contenedores con el nombre, el estado, el uso de CPU y de memoria, y el tráfico de red de cada uno. Es una forma rápida de ver qué contenedor se está comiendo la máquina sin abrir Portainer ni escribir docker stats. Si además quieres exportar estas cifras a un sistema de series temporales y pintarlas en cuadros de mando históricos, Glances puede enviar a Prometheus, InfluxDB o Graphite; para esa ruta más completa tienes la guía de cómo instalar Prometheus con Docker.
¿Cómo usar el modo cliente/servidor y la API REST?
Además de la web, Glances trae dos superpoderes para automatizar. El primero es el modo cliente/servidor: en la máquina que quieres vigilar lanzas Glances en modo servidor (GLANCES_OPT: "-s", puerto 61209) y desde otro equipo te conectas con glances -c DIRECCION_IP, viendo la máquina remota en tu propia consola. Es útil para revisar varios servidores sin abrir un navegador en cada uno:
docker run -d --restart=unless-stopped -p 61209:61209 \
-e GLANCES_OPT="-s" \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
--pid host nicolargo/glances:4.5.5-full
El segundo es la API REST, disponible siempre que el contenedor corra en modo web. En Glances 4 la sirve FastAPI bajo la ruta /api/4, con un endpoint por cada módulo. Estas peticiones devuelven JSON listo para consumir:
curl http://localhost:61208/api/4/cpu
curl http://localhost:61208/api/4/mem
curl http://localhost:61208/api/4/containers
Con esa API puedes alimentar un panel de servicios como Homepage, disparar una alerta desde un script o guardar métricas puntuales. Como el puerto 61208 queda abierto sin contraseña, no lo expongas a Internet tal cual: publícalo detrás de un proxy inverso con HTTPS y autenticación, como se explica en cómo instalar Traefik con Docker Compose. La API también admite token JWT y autenticación básica si necesitas protegerla directamente.
¿Glances o Netdata: cuál elegir?
Ambos monitorizan un servidor desde el navegador, pero resuelven necesidades distintas. Glances es ligero, de una sola pantalla y sin apenas configuración: perfecto para echar un vistazo rápido, revisar un servidor puntual por SSH o consumir métricas concretas por su API. Netdata, en cambio, es una plataforma de observabilidad con miles de métricas de alta resolución por segundo, detección automática, gráficas históricas y alertas incorporadas, a cambio de un consumo de recursos mayor y una interfaz mucho más densa.
La regla práctica: si quieres "el htop de siempre pero en web y con API", quédate con Glances; si buscas un tablero histórico completo con alertas, ve a Netdata. Y si lo que necesitas es un monitor mínimo para varios servidores a la vez, con un consumo casi nulo, mira la guía de cómo instalar Beszel con Docker. No están reñidos: mucha gente deja Glances en cada máquina para el vistazo inmediato y reserva Netdata o Prometheus para el histórico.
Preguntas frecuentes
¿Por qué Glances no ve mis contenedores ni los procesos del host?
Casi siempre es por dos ajustes que faltan en el docker-compose.yml. Para listar los contenedores necesitas montar el socket de Docker con -v /var/run/docker.sock:/var/run/docker.sock:ro; sin ese montaje, la sección de contenedores aparece vacía. Y para que la pestaña de procesos muestre lo que corre en el anfitrión, y no solo el propio Glances, tienes que arrancar con pid: host. Con ambos en su sitio, el panel se rellena por completo.
¿Debo usar la etiqueta latest de Glances?
Mejor no en producción. La etiqueta :latest te dará la versión más nueva cada vez que reconstruyas, lo que puede introducir cambios sin avisar. Fija una versión concreta como nicolargo/glances:4.5.5-full y actualiza cuando tú decidas; el sufijo -full incluye las dependencias opcionales (sensores, GPU) que la imagen básica deja fuera. Así controlas exactamente qué corre y evitas que una actualización automática rompa tu panel.
¿Cuántos recursos consume Glances?
Muy pocos para un servidor doméstico. Al ser un único proceso de Python que lee las métricas con psutil, su huella de memoria es modesta y el uso de CPU se mantiene bajo si dejas el refresco en 1 segundo o más. Si te preocupa el consumo, sube el intervalo de refresco (por ejemplo a 5 segundos) y limita el contenedor con las opciones de recursos de Compose, tal y como explicamos en la guía de límites de recursos y logs en Docker.
Conclusión
Con un solo docker-compose.yml tienes Glances vigilando CPU, memoria, disco, red y contenedores desde el navegador en el puerto 61208, con la API REST de /api/4 lista para automatizar y un healthcheck que confirma que sigue en pie. Es la herramienta ideal para el vistazo rápido y para servidores donde no quieres montar una pila de observabilidad completa. Cuando necesites histórico y alertas, escala a Netdata o a una pila de Prometheus, y protege siempre el puerto tras un proxy inverso antes de exponerlo.