Monitoring Optimization 2010 Report
A few days ago we announced the results of Monitoring Optimization 2010: Trends and Issues Surrounding Network and Security Monitoring from Enterprise Management Associates (EMA). We commissioned EMA for this study in mid-2009 because we found a significant shortage of available data regarding out-of-band / passive monitoring. Quite simply, we have been building out our product strategy with a particular approach in mind. This approach has been validated innumerable times by prospects and customers, but the smart strategist doesn’t build a product based strictly on anecdotal data or a myopic view of the world.
So we took matters into our own hands.
The most eye-opening findings from the study relate specifically to the widespread shortage of network visibility / coverage (81% reported they cannot achieve the visibility they need to monitor appropriately), and why your peers are unable to provide a complete view of network traffic to tools. Specifically, here is our take on the top three reasons for this problem:
- Lack of access to important network traffic. This problem is primarily caused by the shortage of SPAN ports and Taps. With the “old” way, your peers have been forced to buy a new tool for every single network port that requires monitoring. However, you can only activate so many (typically two) before your switch performance degrades. When there is contention for ports, you either have to choose not to monitor certain protocols on some segments or trade off which tool gets access to the port. In the end, living with this problem, particularly in a down economy where budgets are tight, means you are volunteering to have a gap in your coverage.
- Inability to Better Leverage Existing Tools. It amazed me to see that 72% of tools deployed by our respondents were either overloaded and dropping packets, or not used up to their potential. Let me say that again…72%. Nearly three-fourths. How much more could you do if you managed to save a quarter of a million USD? Finally upgrade some old switches? Hire another couple of employees? Come in under budget for a change? Make major strides in your transition to 10G? This really isn’t very hard to fix with Monitoring Optimization.
- Lack of Staff or Key Skillsets. We heard this one loud and clear…your peers have been forced to take on multiple jobs, none of which they can focus on in as much detail as they’d like. Staffs have shrunk due to layoffs and attrition (often planned shrinkage), as well as a shortage of available qualified candidates when positions do come open. And the existing solutions to these problems are simply too difficult to set up, manage, and maintain for various reasons, not the least of which is a shortage of folks who can manage filtering within a command line interface. These trends are not short-term things; they’re here to stay. So you need to improve productivity and enable more of the team to take on tasks that only specialists owned in the past.
We were very pleased to see that EMA agreed with us about what is needed to fix this situation: Monitoring Optimization. But it’s not enough just to provide access to network traffic for your tools; there are several products out there that claim they can give you this benefit. The solution can’t be hard to use, particularly if can only be managed by network architects or other technical specialists. The CLI point is crucial, because while some of you are CLI advocates, most of us have neither the inclination nor the time to learn and master filter rule definition by line code.
Several competing solutions have followed our lead and come out with GUIs that claim to help make this easier. Just take caution, because not all GUIs are created equal. Most of the knock offs I’ve seen are simply pretty icing on a CLI cake.
Sure, you can do some easy dragging and dropping to manage connections and even set up simple filter sets in the GUI (most of which are only applicable if you are lucky enough to need them), but what happens when you really need to roll up your sleeves and do some heavy lifting? Hello CLI.
Why inject further headaches into this process? CLI puts the onus on you to code all the filter rules, maintain the code as various things change in your monitoring assortment, and to manually identify and address any issues with data sharing between multiple tools. Only a fully integrated GUI solves this problem; not a “reactionary” quick-fix to a competing product.
Enough soapboxing. You can read another summary about the research itself on Network World:
Our friends at the Love My Tool blog also gave their take on the study as follows:
Thanks for reading!