gltail turns your servers' network traffic into a 3D blob on your desktop

A weekend tool that watches servers over SSH

gltail.rb, hosted at fudgie.org, is described in the repository as real-time visualization of server traffic, events and statistics with Ruby, SSH and OpenGL. The README opens with an unusually honest paragraph, saying the author knows it is horrible code with global variables and what not, but that it works, and that it is too fun to watch the servers' traffic in real time to clean up everything before releasing it.

That sentence tells you the purpose and the limits at once. This is a tool for one person, on their own desktop, looking at a few machines they administer, right before a release or an incident. It is not a monitoring platform and does not pretend to be one.

The mechanism is simple in outline. The program reads a YAML configuration listing servers, connects to each one over SSH, collects traffic, event and statistics data from them, and renders that data in an OpenGL window on the local desktop.

The repository layout matches that description: a bin/ directory holding the executable, a config.yaml at the root, lib/ for the code, test/ and vendor/ directories, a Gemfile and Gemfile.lock, a Rakefile, a gltail.gemspec, and a .versions.conf file that records the dependency versions the project pins.

Configuration is one YAML file, and SSH is the transport

The configuration section of the README is short and gives you everything you need to get a first run going.

You open config.yaml in a text editor and tweak it to your liking. You might want to save the result to another file and pass that on the command line instead. For access, either include a password for each of your servers or make sure your SSH keys are correctly set up.

That last point is the one to plan for. The README explains that if you need to specify an SSH key, you replace the password entry in the config:

    password: secret

with a key path instead:

    keys: /path/to/key

So authentication is per server, and the config carries either a password or a key path for each host. If you already use SSH keys, the config is the only place you need to change, which is the point of the design: no credentials beyond what SSH already knows about.

Because the transport is SSH, the program inherits SSH's own behaviour, including host key checking and whatever the remote shell allows. That is convenient for an administrator, and it also means gltail can only see what the SSH user can see.

Running it, and the keyboard shortcuts that make it playable

The executable is called gl_tail, and the documented invocations are:

  ./bin/gl_tail --help
  ./bin/gl_tail <config.yaml>

The first prints the usage information, the second runs with a config file.

What makes the program more than a static graph is that it is interactive while it runs. The README lists the keyboard controls: press f to toggle the attempted frames per second, press b to change the default blob type, and press space to toggle bouncing.

The blob type and the bouncing are the two features that suggest what the visualisation actually looks like. The data is drawn as blobs, of which there are several kinds, and they can bounce around the screen, which is a good way to see a burst of traffic as a physical event rather than a line on a graph.

Fullscreen mode is also available. You press shift + f while running, or set fullscreen: true in the config section of your config.yaml.

The frames per second toggle exists because this is an OpenGL program running on a machine that may also be doing other work. Dropping the frame rate on a shared or remote workstation is the difference between a tool you keep open and a tool that makes your fans loud.

The dependency list is from another era, and it shows

The versions tested section is short and dated, and it is the clearest signal about what this project is:

  rubygems    0.9.4
  opengl      0.7.0.pre1
  net-ssh     1.1.2

The opengl gem is at a pre-release version, 0.7.0.pre1, and that is what the install instructions install too, with the --pre flag telling RubyGems to accept pre-release gems. The net-ssh version, 1.1.2, is from the era when net-ssh was a standalone gem rather than part of a modern default stack.

The installation instructions cover four platforms, and each one installs the same two gems, net-ssh and opengl, with --pre and the -r flag for the remote source. On Ubuntu and Debian the system packages needed are rubygems, rake, ruby1.8-dev, the Mesa development libraries libgl1-mesa-dev, libglu1-mesa-dev and libglut3-dev, and build-essential, and then:

  sudo apt-get install rubygems rake ruby1.8-dev libgl1-mesa-dev libglu1-mesa-dev libglut3-dev build-essential
  sudo gem install net-ssh opengl --pre -r

The Mandriva and RedHat path uses urpmi with the equivalent packages, including the rbogl package for OpenGL bindings. Mac OS X assumes Ruby and RubyGems are installed and adds file-tail to the gem list. Windows points at the one-click Ruby installer from rubyforge.org and the RubyGems Package Manager.

The Windows instructions carry one warning worth repeating on any platform: make sure you have accelerated OpenGL installed for your graphics card, because some drivers shipped with a given version of Windows do not include it, and the fix is to install the latest drivers from your graphics card vendor. A software rasteriser will technically run the program, but it is not what the author had in mind.

What the data source gives up, and where the limits are

The limitation of this approach is structural rather than fixable, and it is worth naming before anyone spends an evening on it.

First, the fidelity. The program shows what it can read from a remote host over SSH. The README describes the visualisation in terms of traffic, events and statistics, but it does not specify which counters, which resolution, or which historical window. So the display is a live impression of a host's activity, not a metrics view you can rely on for capacity planning.

Second, the persistence. Nothing in the README describes writing the collected data anywhere. A program that draws blobs and moves on leaves no record, which is exactly why the author uses it to clean up before a release rather than to investigate an incident three days later.

Third, the scale. The configuration lists servers, and the program opens a connection to each. A handful of hosts is the intended case, and a large fleet would mean a large number of SSH sessions and a very busy window.

Fourth, the platform floor. The install path depends on a pre-release gem and on OpenGL being accelerated, and there is no headless mode described, so the program needs a display. The Windows note about drivers is the visible edge of that.

For anything beyond watching a few machines you already administer, a proper agent and time series store will do more, and the honest use of gltail is the quick visual check it was written for.

No releases, an old licence and an open TODO

Two repository facts tell you where the project stands.

The first is that the repository has no GitHub releases. There is no tagged version to install, so you are running the master branch, and the.versions.conf file at the root records the dependency versions the author has pinned so the thing still runs.

The second is the licence file and the surrounding files. The project is under the GNU General Public License version 2, and the root also carries a History.txt, a TODO file, a CLAUDE.md, a Rakefile and a test/ directory, alongside a dist/ directory and a vendor/ directory.

The presence of a Rakefile, a test directory and a gem specification is what makes this different from a single script: it is packaged, it can be built into a gem, and it has a test suite. The dist/ directory is the build output and the vendor/ directory is where vendored gems live, which is what you would expect from a project that pins its dependencies rather than fetching the latest at run time.

On the maintenance side, the last push to master was on 2026-08-09, and there is no GitHub release history to compare it against. The README's own framing, fun but messy code released rather than cleaned up, is consistent with a codebase that is still runnable but not actively extended.

For a GPL-2.0 tool that is deployed on a few machines you own, that is a reasonable trade. For anything embedded in a product, the licence terms and the absence of releases are both reasons to look elsewhere.

Editorial conclusion

Adopt gltail if you run a handful of servers you already have SSH access to and want a live picture of their network activity without building a monitoring stack, since the program is a small Ruby tool with a YAML config and an OpenGL window. Do not adopt it for production observability, for a fleet of many hosts, or if you need a durable record of what happened, because the display is transient and the project is a weekend tool by the author's own description. Before you run it, check that your servers accept the SSH credentials you put in the config, expect to install the opengl gem in pre-release form, and note the maintenance picture, with the last push on 2026-08-09 and no GitHub releases published, so you are tracking the master branch rather than a tagged version.

Frequently asked questions

Official sources

1. Fudge/gltail on GitHub
2. Issues
3. License: GPL-2.0
4. Project website
5. README