Synthetic Monitoring
Written by: Richard Clinton, Guest blog post writer for Apica
In a previous lifetime, when the world was not so fully digital, the Internet was just a nascent ARPAnet, and my job was manufacturing first-gen word processors, I worked alongside a bonafide genius named Mark. His troubleshooting skills were unmatched and his solutions were often both elegant and surprising. He would take on system or component problems that the rest of us lowly techs could only begin to fathom and shortly have the root problem diagnosed and have repair instructions in place. He was the first tech I saw use the concept of a low-voltage, high current pulse to eliminate a solder short in the middle layers of a multi-layer printed circuit board. He also detected manufacturing errors, like finding resistors that were the wrong value (by a factor of a thousand) being placed in circuits because the rework crew didn’t check the color codes properly and had put the wrong value resistors in a replacement drawer. We newer techs agreed among ourselves that he could “talk to the machines” and I worked with him as often as I could to try and learn this valuable skill.
It turns out that he could, indeed, talk to the machines because he understood at an intimate level how electronics work and the kinds of physical and logical protocols used by the machines to talk to each other. He could watch them failing their diagnostic tests and quickly weed out irrelevant and misleading symptoms and cut right to the heart of why a printer wouldn’t print or a hard drive wouldn’t communicate with the Device Under Test. He understood that every electronic device has a limited set of instructions to work from, a specific protocol for communicating those instructions and has a limited number of responses to those instructions. All he had to do was to recognize where the electronic ‘conversation’ was going astray and then focus his considerable skills in determining the root cause of the problem. In due time, I was able to talk to the machines myself, though never as thoroughly and competently as Mark had.
Understanding and troubleshooting today’s miracles – websites, applications, transmission protocols at seven different layers – can be a daunting task. It can often take more than a simple WireShark monitoring session to dig deeply enough into why a website isn’t working properly or is sloth-slow. How do you talk to the machine to find out if conversations are timing out because (a) the website is built badly or (b) the network is having congestion or transmission quality problems or (c) the database is being overwhelmed with requests for information?
If you’re Mark, you sit down, grab a line monitor and step through multiple transactions to see what you can see. If you’re not quite Mark yet, your best bet is a well-developed Synthetic Monitoring package that will allow you to see not just what the requests and responses are at a high level, but will give you a deeper, more fully informative view of processes happening at different OSI layers along with timestamps that can identify where processes are taking too long or where traffic is so overwhelming that processes have to slow down due to machine constraints.
So, if you’re not Mark you should take the time to find out your options in the monitoring solutions marketplace and grab hold of the best one you can find. Find one that comes with world-class support so you can get up to speed on it quickly and one that does not require the purchase of insanely-priced hardware that will eat up your profits. Then go to town on your website problems and weed out the bottlenecks, redundancies and coding errors to get your website operating at its maximum potential. If you are Mark, then – HI!!! Long time, no see. We should work together again.