Monitoring Host Health with Glances

The first question when a homelab service feels slow is usually: “is the host healthy?”. Answering it needs something quick to open and cheap to run. A full stack like Prometheus and Grafana is powerful, but for a single machine with limited storage, the operational cost feels excessive. That is where Glances fits: a Python-based monitoring tool that reports host state comprehensively, yet stays light enough to run as a single container.

Why Glances

The need started simple: see CPU, RAM, disk, and containers in one screen. Before, I had to run htop, df, and docker stats separately, then assemble the picture manually. Glances pulls everything into a single dashboard, so the cause of a problem is spotted faster instead of guessed at.

Integration was the second reason. Glances is not just a dashboard — it ships a REST API. Host metrics can be consumed by other dashboards such as Homepage, or by custom scripts doing health checks.

How Glances Works

Glances runs as a Python process that reads OS metrics through plugins: CPU, memory, swap, load average, disk I/O, filesystem, hardware sensors, network, and processes. For containers, it talks to the Docker daemon through the socket and reports per-container resource usage.

The tool has several modes: interactive terminal, web server (-w), client/server for monitoring other hosts, and a REST API. The current API is version 4, for example GET /api/4/quicklook returns the quicklook summary as JSON. The modular plugin structure keeps Glances focused: only relevant plugins are active.

Deployment with Docker Compose

Docker Compose is the cleanest way to run it in a homelab. Two settings are required for accurate metrics: the container must see host processes (pid: "host") and use host networking so network interfaces are read correctly:

services:
  glances:
    image: nicolargo/glances:latest
    container_name: glances
    restart: unless-stopped
    pid: "host"
    network_mode: "host"
    environment:
      - GLANCES_OPT=-w
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro

In web server mode the UI is served on the default port 61208 and the API under /api/4/.... Extra options pass through GLANCES_OPT, e.g. -w --password to enable authentication.

Security & Operations

Read-only Docker socket. The /var/run/docker.sock volume is mounted with :ro. The container can read the daemon but cannot change Docker state.
Web authentication. Web mode runs unauthenticated by default. Glances supports username/password via --username / --password, including JWT authentication through POST /api/4/token. For external access, put it behind a reverse proxy with auth rather than exposing the port publicly — or simply restrict it to the local network.
Daily usage. The quicklook page lives at http://localhost:61208; for rapid debugging over SSH, terminal mode (glances) stays practical.
Configuration & recovery. CLI options can move into a glances.conf file. Back it up with the compose definition so the config survives container loss.

Strengths I Noticed

One command, many metrics. CPU, RAM, disk, temperature, network, and containers appear together. Initial diagnosis is much faster than opening three different tools.
Cheap to run. A Python process in web mode; no database, time-series storage, or extra component to maintain.
Ready-to-use REST API. Without extra setup, external dashboards can read data through JSON endpoints such as /api/4/quicklook.
Client/server mode. If monitoring more than one host becomes necessary later, Glances has a built-in client/server mode without switching stacks.

Cons and Limitations

Not a full monitoring stack. Glances shows the current state with limited history. For long-term metric retention and complex alerting, a solution like Prometheus is still required.
Authentication is off by default. Without --password or protection in front of the reverse proxy, anyone who can reach port 61208 can view host metrics. Easy to overlook during first setup.
Host networking has trade-offs. With network_mode: "host", the container loses its own network isolation; that trade-off is accepted for metric accuracy.
Single-host scope. Glances monitors the host it runs on (or the target host in client mode); it does not discover or aggregate services across the homelab automatically.
Metrics, not logs. For logs or tracing, Glances is of no help — that is another tool’s domain.

Conclusion

Glances is the right fit for a single-machine homelab: instant visibility into host and container health without the operational weight of a large monitoring stack. It answers “is the host healthy?” quickly, and the REST API makes it easy to integrate with other dashboards.

It is not the answer to every observability need, though. Environments with many hosts, long-term metric retention, or complex alerting still demand a heavier solution. For my context — one machine, limited storage, quick-glance priority — Glances sits at the right spot.