I was chatting with a customer recently, who is also a gear-head (car and motorbike enthusiast), and over a beer we started to analogize the state of IT system monitoring to that of car monitoring.
When you think about how we monitor fuel in a car, and see how it has evolved over the last century, you have to wonder why for many companies their thinking around monitoring hasn’t followed a similar path.
When the internal combustion engine-based car was first invented, checking the amount of fuel in the tank, meant tapping the side of the tank to see from the echo If it was full or not (We discussed that some people may have opened the filler cap and peered inside with a lit match, to visually check the level, but Darwin awards folklore can tell that story).
Then quite quickly cars came with a dipstick that could allow the user to check the levels a little more accurately, if somewhat messily.
Then a float and mechanical lever was added to the fuel tank to give an external reading of the level of fuel. Which worked well if you were stopped on a flat surface; but could be inaccurate in other conditions.
Then came the dashboard fuel gauge, which was the accepted model for decades, gradually getting more and more accurate. Then the little red light that let you know that you had better get some more fuel soon.
More recently cars advise of the available range left in the tank. Initially these were wildly inaccurate, but over time have started to calculate recent conditions to calculate the range.
My car today has a really accurate reading of the available fuel, and it’s linked to the cars GPS and the internet via LTE. My car will alert me when I need more fuel, analyze the published prices of stations on my route and advise of the best one to go to that is closest to the route I’m taking.
So, cars have moved from providing data, to aggregating data into information and then abstracting this information into useful knowledge.
Monitoring systems are today quite good at collecting data, and some are okay at aggregating data (with the help of staff writing and maintaining complex scripts), but very few offer the ability to automatically abstract information in ways that pre-empt issues and provide meaningful pro-active actions to avoid performance issues.
It’s time for a better way to drive real improvements of MTBF (Mean Time Between Failures) and MTTR (Mean Time to Repair) for business applications.
That’s exactly what Nastel is delivering www.nastel.com
#nastel #APM #360degreesituationalawarenes #monitoring #MTBF #MTTR #decisionsupport