Skip to main content

Auralization - short wave radio for network management

Many moons ago I was reading Terry’s blog when he was at Netcordia, where he posted about auralization which reminded me about my own experiments in using voice for monitoring a network. Not strictly auralization, but stay with me. A few years ago, I created a monitoring system based on Suse and using Argus. I created a call me system using text to speech and Openh323. The voice integration was driven using an old Radvision H.323 gateway that Madge OEM'ed way back in the 90s.

What this monitoring system did was phone me at a designated number and tell me in an automated voice message what the problem was. No SMS or pager bull, just a plain voice (I could never read a SMS at 2:00am!). I also had a feedback channel via DTMF. It cost zilch and worked like a charm! The gateway was an inheritance from when Madge went titsup, the server was an old Internet caching appliance and the software was open source. My code is long lost, but the strength of using audio and voice has remained in my thoughts. Is there any software out there today that does the same thing? I also thought of doing a flight director poll. The idea would be that I call in and the system would give feedback in much the same way the flight director of an Apollo mission would have heard in Mission Control. “Backbone we are go”, Kalahari Edge, we are no go as the systems are at 90%.”, "Backup we are go." etc. Never got around to doing it as I became a manager and lost all of my ability to program. :-)
Ok, after that slight diversion back to back to Terry’s post about auralization which is the same as visualization but with sound. My idea would be the short wave radio. The short wave radio has many possible auralizations:
  • Hum variation based on network utilization.
  • Static pops based on errors
  • Feedback loop spikes based on failures
  • Morse code alerting SOS . . . - - - . . . for a major incident as an example
  • Automated tune in to weather report or traffic report, e.g. "email from the Kalahari to the outback has increased resulting in a jet steam congestion".
  • Random timed tune in to the flight director poll described above.
  • Tornado warnings based on incidents spikes at the service desk.
  • or basically any other radio-centric voice or sound effect.
There are many sources for determining sounds, including syslogs, snmp traps, netflow, icmp and ipsla. In a large network the amount of information being generated by the network and the number of issues can be relatively high and the sounds can become a trigger for proactively detecting major incidents.
However, the big thing is, does the younger generation recall short wave radio???????? I have an old 1948 Murphy, so maybe the above just appeals to me??


Popular posts from this blog

Why Madge Networks, the token-ring company, went titsup

There I was shooting the breeze with an old mate. The conversation turned to why Madge Networks which I wrote about here went titsup. My analysis is that Madge Networks had a solution and decided to go out and find a problem. They deferred to more incorrect strategic technology choices. The truth of the matter is that when something goes titsup, its not because of one reason only, but a myriad of them all contributing to the negative consequence. There are the immediate or visual ones, which are underpinned by intermediate ones and finally after digging right down, there are the root causes. There is never a singular root cause for anything but I'll present my opinion and encourage everyone else to chip in. All of them together are more likely the reason the company went titsup. As far as technology brainfarts go there is no better example than Kodak . They invented the digital camera that killed them. However, they were so focused on milking people in their leg

Flawed "ITIL aligned"​ Incident Management

Many "ITIL aligned" service desk tools have flawed incident management. The reason is that incidents are logged with a time association and some related fields to type in some gobbledygook. The expanded incident life cycle is not enforced and as a result trending and problem management is not possible. Here is a fictitious log of an incident at PFS, a financial services company, which uses CGTSD, an “ITIL-aligned” service desk tool. Here is the log of an incident record from this system: Monday, 12 August: 09:03am (Bob, the service desk guy): Alice (customer in retail banking) phoned in. Logged an issue. Unable to assist over the phone (there goes our FCR), will escalate to second line. 09:04am (Bob, the service desk guy): Escalate the incident to Charles in second line support. 09:05am (Charles, technical support): Open incident. 09:05am (Charles, technical support): Delayed incident by 1 day. Tuesday, 13 August: 10:11am (Charles, technical support): Phoned Alice.

Updated: Articles by Ron Bartels published on iot for all

  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all .  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all . Improving Data Center Reliability With IoT Reliability and availability are essential to data centers. IoT can enable better issue tracking and data collection, leading to greater stability. Doing the Work Right in Data Centers With Checklists Data centers are complex. Modern economies rely upon their continuous operation. IoT solutions paired with this data center checklist can help! IoT Optimi