How To Make Management of Monitoring Filters Simple
Some engineers think that command line interfaces (CLI) for managing monitoring equipment are a good idea. In fact, I’ve met a couple engineers at tradeshows that think a CLI is great because it gives them “more granular control of the filter output” that they create. While a CLI may work for them, it’s a bad idea for most IT staff, according to a recent study and whitepaper by ZK Research.
You may be asking, "Why is it a bad idea?" The answer is simple:
- A CLI takes too long for configuring filters
- The filters created using CLI are error prone
- The CLI creates unnecessary complexity—there is a better, easier method
- And creating filters with a CLI costs more money, when compared to a graphical user interface (GUI)
According to the ZK Research whitepaper, here are a few facts to back up those statements:
- At least 20% of monitoring filters created through a CLI have errors
- 35% of network downtime is caused by human error
- 50% of network managers spend almost half of their time just to configure monitoring tools
With all of the responsibilities that you have, do you really want to spend your precious time creating data filters for monitoring tools? Creating a filter should be easy. A good network packet broker (NPB) will do that for you.
Here’s an example comparing CLI to a graphical user interface (GUI). Most engineers should be familiar SPANs (mirroring ports) that are commonly available on their network switches. SPANs can be used instead of a dedicated packet broker to create monitoring filters. However, compare the two options side by side. Which one looks better?
Once an NPB is installed in the network, Change Board approvals are typically not required when creating or modifying monitoring filters. This is because the NPB is out of the flow of the core network data. The exception would be an NPB that is deployed for inline security and monitoring tools.
The filter creation process for the NPB (like an Ixia NPB) is also a lot faster. You simply log in, use drag and drop and point & click visual capabilities to create a filter. This takes 2 to 5 minutes. A drag and drop interface has an extremely short learning curve. All of the complexity of designing a filter, creating it, and testing its accuracy have been abstracted away for you. With a CLI interface you typically need to log in, write the filter using Boolean algebra, activate the filter through a command, and then validate the filter output. Even if you are a wizard at CLI, this will take you 15 to 30 minutes at least. It’s more common for it to take an hour or more.
The length of time to create a filter with CLI is also non-linear, as shown in the ZK Research whitepaper. This is because more time is needed to ensure that additional filters are delivering all of the requisite data to the security and monitoring tools—basically to make sure the additional filters aren’t clipping relevant data for the tools. This is a fairly common problem.
At the end of the day, filter creation needs to be quick, simple, and hitless. Look for a solution that uses an intuitive interface. Intuitive means drag and drop and point and click. This way, you don’t need training—you can just jump right in and start using the system. There is no CLI or Boolean algebra required.
The Vision ONE system and IxVision architecture uses a drag and drop user interface that is simple to understand and simple to use.
Check out the whitepaper from ZK Research Simplified Programming of a Visibility Layer Can Have a Big Impact on Application Performance or this website if you want more information.