Listening to my server

The first server I connected to the Internet sat on the floor of my office, close enough so I could hear -- and feel -- its response to heavy load. It seems weird to admit that I relied on those sensory cues, but I've talked to enough system administrators to know I'm not alone. The sounds of a working machine enable the pattern recognition engine in your brain to create a baseline -- and to detect deviations from it -- in ways that are effortless, automatic, and incredibly efficient.

Of course server co-location doesn't normally mean keeping the box 12 inches from your right knee. And even when you can do that, sound and vibration are only crude indicators of status. So we look at dashboards and read reports to monitor the day-to-day health of our systems, and we reserve sound (or vibration) for the exceptional pager alert.

What if you could translate system events into a symphony? Michael Gilfix's Peep, a "network auralizer," explores the idea. In a paperdelivered at the Usenix Association's Large Installation System Administrators (LISA) conference in 2000, Gilfix described Peep's naturalistic vocabulary of sounds. A discrete event, such as a user logging in or an error message appearing in a log, maps to a single staccato sound -- for example, the chirp of a cricket. A variable state, such as the number of users or the current system load, maps to a continuous sound -- for example, wind or running water.

It's such a charming notion I had to try it out. What I found, after building the current version of Peepand installing it on a Red Hat Linux box, is that "sonification" of system status is not so different from visualization of the same data. Both are hard problems. First you have to get hold of the raw data. It's all sitting there in the logs, but digging it out in a useful form is easier said than done. Peep, for example, hauls in a flock of CPAN (Comprehensive Perl Archive Network) modules to deal with the various formats. If it ran on Windows, it would need a different set of modules. In a network of XML Web services, solving at least this part of the problem should be a lot easier.

The next part -- creating useful representations of states (how things are) and events (how things change) -- is always going to be hard. Edward Tufte's books lay out the rules for creating rich and effective visual information displays. Of course, we rarely see these principles applied successfully in books and magazines, never mind in system monitoring software. When the Tufte of sonic design emerges, he or she will likely suffer a similar fate.

Despite this gloomy assessment, I'm hopeful for Peep and its successors. To function well in complex information environments, we'll need to attune all of our senses to the patterns of stasis and change. As we are still learning, different modes of perception offer complementary strengths. In his Weblog, Ray Ozzie has celebrated the virtues of modality. "The universal inbox was supposed to have merged e-mail and voice mail by now," Ozzie wrote, "but such products remain niche. Hard as it is for technologists to believe, people actually like dealing with these separate modalities separately."

Now if you'll excuse me, the crickets are chirping madly and I think I'll go find out why.