Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Fri, Jan 20, 2012 at 12:24:26PM -0500, David Blank-Edelman wrote: > On Jan 19, 2012, at 5:34 PM, Tom Metro wrote: > > I've heard of tools that let you listen to LAN traffic, where supposedly > > you can easily hear the differences when something unusual happens. But > > I'd expect such a tool to get annoying fast. I'm inclined to agree with this, though I must admit I find the idea somewhat intriguing... I'm wondering if anyone has actually used this for real monitoring. If so, how did you find it? > You are thinking of Peep (which has as its goal not to be too annoying): Perhaps so. Still, this kind of tool strikes me as most useful when the computing environment being monitored is large enough to require a team to do the job, and I think therein lies the trouble. I expect many people probably could block out the background noise, whereas others might have a great deal of trouble. I'd imagine the specific noises emitted would affect that balance; different people react differently to different types of sounds, much as different people appreciate different types of music. I suspect it would take some experimentation and quite a bit of luck to find a set of noises which would not irritate at least one member of your team. This seems like a potentially serious drawback, though it likely depends on the composition of your team. The paper discusses the idea that typical network monitoring tools are reactive and therefore interrupt-driven, and that they only provide negative feedback, and no positive feedback. But I'm not sure I really see a difference: Traditional tools provide positive feedback in the form of silence, much like most command line tools in a Unix environment. No news is good news. Peep is still reactive in that when things sound "normal" there's nothing for the engineer to do; only when the sounds change in a way that sounds abnormal must one then react and investigate what is happening. It seems to me that another downside is that one must learn to interpret what the sounds mean. There are potentially dozens or even hundreds of events which could happen on your network that might need their own sounds assigned. With traditional tools, any reasonably technical person can simply read the alert/page/whatever and see what the problem is, without having to memorize some kind of unintuitive code that represents the problem. Paging or some sort of audible alerting can be used to trigger action, so that only infrequent active monitoring, or even none at all, is required. My impression is that this mostly is a clever hack without much practical value. But if anyone is using this (or some similar tool) with some degree of effectiveness, I'd certainly like to hear about your experience. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |