Comprehensive System and Container Monitoring via Glances Docker Implementation

Glances is a sophisticated, open-source, cross-platform system monitoring tool designed to provide a holistic view of a machine's health and performance. Written in Python, it leverages specialized libraries to extract raw data from the underlying hardware and operating system, presenting it through a highly readable dashboard. While it excels at monitoring standard system metrics such as CPU utilization, memory consumption, disk I/O, and network throughput, its true power is realized when integrated with containerization environments. Glances allows for the real-time monitoring of not only the host machine but also individual container processes, including those managed by Docker and LXC.

The architecture of Glances is designed for versatility, offering multiple interfaces for data consumption. Users can interact with the tool via a traditional command-line interface (CLI) for immediate, local analysis, or deploy it in a client/server configuration. In this server mode, remote monitoring is facilitated through a Web interface or via an API supporting XML-RPC and RESTful requests. This flexibility makes it an ideal solution for both individual developers managing a single workstation and system administrators overseeing vast server clusters. Furthermore, Glances integrates with modern AI ecosystems, allowing AI assistants such as Claude and Cursor to query system data directly via a built-in MCP server, a feature available in version 4.5.1 and higher.

For users operating in containerized environments, Glances provides a standalone Docker image. This allows the monitoring tool to run as a container itself while maintaining visibility into the host system and all other running containers. By leveraging specific Docker flags and volume mounts, Glances can break through the standard container isolation to gather critical performance data, making it a lightweight alternative to heavy-weight monitors like Portainer. The ability to export statistics to CSV, JSON files, or external time-series databases ensures that Glances can fit into any monitoring pipeline, whether for immediate troubleshooting or long-term trend analysis.

Core Monitoring Capabilities and System Metrics

Glances is engineered to provide a comprehensive snapshot of system health. It does not merely report single values but tracks a wide array of interdependent metrics that allow an administrator to identify bottlenecks and resource contention.

The fundamental monitoring capabilities include:

• CPU Usage: Real-time monitoring of processor load, allowing users to see if the system is CPU-bound.
• Memory: Tracking of RAM usage, including used and free memory, and the /MAX ratio to understand the overhead.
• Disk I/O: Monitoring of read and write operations per second (IOR/s and IOW/s), critical for identifying slow disk performance.
• Network Usage: Monitoring of received and transmitted data per second (Rx/s and Tx/s) to analyze network congestion.
• Process Monitoring: Detailed view of running processes, including their specific resource consumption.
• User Activity: Tracking of currently logged-in users on the system.
• Hardware Health: Monitoring of temperatures, voltages, and fan speeds to prevent thermal throttling or hardware failure.

These metrics are presented in an intuitive dashboard that can be customized. This customization allows users to filter out irrelevant information and focus exclusively on the specific parameters that impact their application's performance. The use of Python as the primary language ensures that Glances can be extended and adapted to various operating systems, maintaining its cross-platform nature across Linux and macOS.

Deployment via Python and Pipx

For users who prefer to install Glances directly on their host machine rather than running it inside a container, Python provides the primary installation path. To avoid the common issue of "dependency hell"—where globally installed packages conflict with one another—the use of pipx is highly recommended.

pipx manages virtual environments for each application automatically, ensuring that Glances and its required dependencies are isolated from the global Python environment. This is particularly critical when installing the Docker plugin for Glances, as it requires specific libraries to communicate with the Docker daemon.

The installation process using pipx involves two primary steps:

1. The initial installation of the Glances core package:
   pipx install glances

2. The injection of the Docker-specific dependencies into the created virtual environment:
   pipx inject glances "glances[docker]"

Upon successful execution, the system will display a confirmation message indicating that the package has been injected into the venv glances. Once this process is complete, running the glances command will automatically include detailed information about running Docker containers. This method is ideal for those who want the lowest possible latency and the most direct access to system resources without the overhead of a container wrapper.

Docker Implementation and Image Varieties

Running Glances as a Docker container is a powerful strategy for maintaining a clean host environment while still gaining deep visibility into the system. The official images are provided by nicolargo and are available in several flavors to suit different needs regarding size, stability, and dependencies.

The available Docker tags are categorized as follows:

• latest-full: A full Alpine-based image containing all dependencies for the latest release.
• latest: A basic Alpine-based image with minimal dependencies, specifically including FastAPI and Docker.
• dev: An Alpine-based image derived from the development branch; it contains all dependencies but is explicitly marked as potentially unstable.
• ubuntu-latest-full: A full Ubuntu-based image with all dependencies for the latest release.
• ubuntu-latest: A basic Ubuntu-based image with minimal dependencies, including FastAPI and Docker.
• ubuntu-dev: An Ubuntu-based image based on the development branch; it contains all dependencies but may be unstable.

The choice between Alpine and Ubuntu images typically depends on the user's preference for image size versus compatibility. Alpine images are significantly smaller, reducing the attack surface and storage requirements, while Ubuntu images provide a more traditional environment that may be preferred for certain complex dependency chains.

Executing Glances in Console Mode

Console mode is designed for users who want to interact with Glances via a terminal interface. This mode provides an immediate, real-time dashboard. To ensure that Glances can monitor the host and other containers, specific flags must be used during the docker run command.

To run the latest full Ubuntu version in console mode, the following command is used:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock:ro --pid host --network host -it nicolargo/glances:ubuntu-latest-full

The technical requirements for this command are explained in the following table:

For those using Podman or needing specific timezone settings, the command can be expanded:

docker run --rm -e TZ="${TZ}" -v /var/run/docker.sock:/var/run/docker.sock:ro -v /run/user/1000/podman/podman.sock:/run/user/1000/podman/podman.sock:ro --pid host --network host -it nicolargo/glances:latest-full

In this variation, the -e TZ="${TZ}" flag ensures that the logs and timestamps within Glances match the host's local time, and the addition of the Podman socket allows the tool to monitor Podman containers in addition to Docker.

Deploying Glances in Web Server Mode

For remote monitoring, Glances can be deployed as a background service that serves a Web UI. This is achieved by passing the -w flag through the GLANCES_OPT environment variable.

To deploy the Ubuntu latest full version in Web server mode, use the following command:

docker run -d --restart="always" -p 61208-61209:61208-61209 -e GLANCES_OPT="-w" -v /var/run/docker.sock:/var/run/docker.sock:ro --pid host nicolargo/glances:ubuntu-latest-full

The key components of this deployment are:

• -d: Runs the container in detached mode, allowing it to operate in the background.
• --restart="always": Ensures the monitoring tool starts automatically after a system reboot or container crash.
• -p 61208-61209:61208-61209: Maps the internal ports to the host, allowing access to the Web interface via a browser.
• -e GLANCES_OPT="-w": This is the critical environment variable that tells the internal Python process to start the Web server.

Users can further refine this deployment by adding timezone support and Podman compatibility:

docker run -d --restart="always" -p 61208-61209:61208-61209 -e TZ="${TZ}" -e GLANCES_OPT="-w" -v /var/run/docker.sock:/var/run/docker.sock:ro -v /run/user/1000/podman/podman.sock:/run/user/1000/podman/podman.sock:ro --pid host nicolargo/glances:latest-full

This configuration allows a system administrator to access the dashboard from any device on the network by navigating to the host's IP address on port 61208.

Advanced Configuration via glances.conf

While Glances provides sensible defaults, advanced users can customize the behavior of the tool—such as which plugins to load or how often to refresh data—using a glances.conf configuration file.

There are three primary ways to implement a custom configuration file in a Docker environment:

1. Volume Mounting:
   Users can mount a local configuration file directly into the container. This is the most flexible method as it allows for changes without rebuilding the image.

docker run -vpwd/glances.conf:/glances/conf/glances.conf -v /var/run/docker.sock:/var/run/docker.sock:ro -v /run/user/1000/podman/podman.sock:/run/user/1000/podman/podman.sock:ro --pid host -it nicolargo/glances:ubuntu-latest-full

2. Custom Dockerfile:
   For a more permanent deployment, the configuration file can be baked into a new image.

dockerfile FROM nicolargo/glances:ubuntu-latest-full COPY glances.conf /glances/conf/glances.conf CMD python -m glances -C /glances/conf/glances.conf $GLANCES_OPT

3. Dynamic Environment Variable Mapping:
   Users can map the configuration file and tell Glances to use it via the GLANCES_OPT variable.

docker run -e TZ="${TZ}" -v $HOME/.config/glances/glances.conf:/glances.conf:ro -v /var/run/docker.sock:/var/run/docker.sock:ro -v /run/user/1000/podman/podman.sock:/run/user/1000/podman/podman.sock:ro --pid host -e GLANCES_OPT="-C /glances.conf" -it nicolargo/glances:latest-full

By using the -C flag within GLANCES_OPT, the user explicitly directs the Python process to load the specified configuration file instead of the default one located at /etc/glances/glances.conf.

GPU Monitoring and Resource Constraints

Modern workloads, particularly those involving Machine Learning or heavy rendering, require visibility into GPU utilization. Glances supports this, but since GPU hardware is not natively accessible to standard containers, the Docker engine must be configured to allow the pass-through of GPU resources.

To enable GPU monitoring, users must follow the official Docker documentation regarding resource constraints. The primary requirement is the inclusion of the --gpus flag in the docker run command.

It is critical to note that the --gpus flag must be placed before the image name in the command sequence for it to be recognized by the Docker engine. A typical implementation would look like this:

docker run --rm --gpus all -v /var/run/docker.sock:/var/run/docker.sock:ro --pid host --network host -it nicolargo/glances:ubuntu-latest-full

Without this flag, Glances will be unable to poll the GPU drivers, and the corresponding metrics will be missing from the dashboard.

Docker Compose Implementation

For users managing multiple services, deploying Glances via Docker Compose provides a streamlined way to maintain configuration and ensure that the monitoring service is integrated into the overall stack.

A typical docker-compose.yml configuration for Glances looks as follows:

yaml monitoring: image: nicolargo/glances:latest-alpine restart: always volumes: - /var/run/docker.sock:/var/run/docker.sock environment: - "GLANCES_OPT=-w" ports: - "61208:61208"

In this configuration:
- The latest-alpine image is used to keep the footprint small.
- The Docker socket is mounted, allowing Glances to see other containers.
- The -w option is passed to enable the Web UI.
- Port 61208 is exposed to the host.

To launch this service, the user simply navigates to the directory containing the compose file and executes:

docker-compose up

This will start the Glances server with the WebUI enabled, providing a persistent monitoring solution that starts automatically with the rest of the infrastructure.

Comparative Analysis: Glances vs. Heavyweight Monitors

When choosing a monitoring tool, users often compare Glances with heavy-weight options like Portainer. While both can monitor Docker processes, they serve different primary purposes.

The following table highlights the distinctions between a lightweight monitor (Glances) and a heavy-weight manager (Portainer):

Glances is the superior choice when the objective is to quickly identify which container is consuming excessive CPU or memory without needing to navigate complex management menus. It provides the "essentials" (Name, Status, CPU%, MEM, /MAX, IOR/s, IOW/s, Rx/s, Tx/s, Command) in a single view, allowing for rapid diagnosis.

Analysis of System Monitoring Architecture

The architectural design of Glances is centered on the concept of modularity. By utilizing Python, the tool can act as a bridge between low-level system calls and high-level user interfaces. When running in a Docker container, the tool's ability to monitor other containers relies entirely on the access provided to the Docker socket (/var/run/docker.sock).

The Docker socket is the entry point to the Docker API. When Glances mounts this socket, it can query the API for a list of running containers, their resource usage, and their status. However, the socket alone is insufficient for full system visibility. To see the actual process IDs (PIDs) and accurately map resource consumption to specific system processes, the --pid host flag is mandatory. This allows the container to "see" the host's process table, effectively bypassing the namespace isolation that normally prevents a container from knowing what is happening on the host.

Furthermore, the use of --network host ensures that the network metrics reported by Glances are not those of the container's virtual network interface, but those of the actual physical network cards of the host. This creates a transparent monitoring layer where the tool exists as a container but operates with the visibility of a native host application.

The integration of the MCP server in version 4.5.1 represents a shift toward AI-driven operations (AIOps). By allowing AI assistants to query Glances, the manual task of interpreting graphs and logs is reduced. An AI can analyze the current CPU and memory trends and suggest optimizations or identify anomalies based on the raw data provided by the Glances API.

Conclusion

Glances represents a highly efficient bridge between simple system monitoring and complex container orchestration. Its ability to deploy as a standalone container—while maintaining host-level visibility via the Docker socket and PID namespace—makes it an indispensable tool for any environment utilizing Docker or Podman. Whether deployed via pipx for local host access or through a Docker Compose stack for remote Web-based monitoring, Glances provides an exhaustive set of metrics including CPU, memory, disk I/O, and network throughput.

The flexibility offered by various image tags (Alpine vs. Ubuntu, Latest vs. Dev) ensures that users can balance stability and resource usage according to their specific requirements. The inclusion of GPU monitoring through the --gpus flag further extends its utility into the realm of high-performance computing and AI workloads. Ultimately, Glances succeeds by providing a "single pane of glass" for system health, offering a lightweight alternative to management-heavy tools and integrating seamlessly with modern AI assistants for automated system analysis.

Sources

1. Dev.to - Glances Docker Processes
2. GitHub - Nicolargo Glances
3. Docker Hub - nicolargo/glances
4. Google Groups - Glances Users