Most organizations realize that they need to be monitoring their applications, databases and network equipment for availability and health. Waiting for an application to crash or become unavailable is not an option. There is downtime, loss of productivity and revenue loss that many organizations cannot afford. Any potential application availability issues need to be identified and dealt with before they morph into downtime.
There are a number of solutions on the market designed to monitor network infrastructure. Most are proprietary and a few are open source. They come with a wide range of capabilities and prices. All the vendors tout their capabilities, their cost effectiveness, and ease of use. The pitches can be very compelling and make their solutions appear to be very simple and straightforward. Very few vendors will be forthright about any technical challenges regarding their solutions, and they certainly will not be forward about any licensing gotchas. It can be difficult to wade through the marketing materials, documentation, and licensing options to pick the right solution. So where exactly do you start?
Picking the right solution normally boils down to two things, cost and complexity. However, I’m going to expand those two areas into four, which should give you a better insight into each of them.
You might be saying to yourself, we will deal with the technical stuff after we acquire the solution, but that would be a mistake. If the install process for the solution is complex or a mess, it may be the first indication of what awaits you maintaining and using the solution. Get a hold of the installation manual for the solution. Even if you are not technical, read it over. If it is more than a page of steps, is complex, or just does not make any sense, this may be an indication that the vendor has architectural and/or development issues with their solution. If the installation process is clean and easy, it likely means that the vendor put some thought into it, and likely did the same throughout the solution. If the vendor has more than one release of their solution, take a peek at the upgrade process from the previous version. This is typically an area where vendors place little focus, and where architectural deficiencies show themselves. Many upgrade processes can be very convoluted and complex. You can generally find installation docs online with a little effort. If you cannot, ask the vendor for them. If they will not readily provide them to you, move on.
You might be thinking to yourself that licensing is fairly cut and dry. You get a quote from the vendor for the licensing and that it is. Unfortunately many network monitoring and management (NMM) vendors have developed a few twists to their licensing schemes that can be a little hard to spot, and can come back to bite you later. Most NMM vendors are agent-based, meaning they utilize installed agents on platforms to collect data beyond simple availability. Some call them “monitors” or “elements”, while others have different names for them. In most cases these are licensing points that you need to play close attention before you buy. The game is to offer you a set number of agents in order to make it financially appealing at the beginning. You implement the solution on a limited basis and get comfortable with it. Once you want to expand it to other areas of your network infrastructure, this is where the shock can occur. The licensing costs involved in expanding the scope of many solutions can be very expensive.
The other licensing element to keep an eye on is the server installation. Nearly all of the solutions on the market typically have a central server install at their core. Their server install is the main repository for their functionality, communications, and alerting. It’s kind of a traffic cop in a busy intersection, and there are scalability limitations to this architectural approach. As you increase the number of monitoring points and load, you will at some point exceed the server’s capabilities to handle them all. With some vendor solutions this will occur quickly, while others will take a little longer. If you expand the use of the product beyond the capabilities of the server, you will need to add a new server install, which will require a new license, and can be very expensive. Pay close attention to scalability of the solution relative to a single central server install, and the size of your network. Negotiate a second server install upfront if you think you will eventually need it.
Support is always a critical element. If something goes wrong with the solution, how responsive will the vendor be towards addressing any issues? What kind of support do they offer? Do they offer phone, email and/or forum support. Is support included with the licensing of the solution, and if so for how long? Some will offer email support, but charge you for phone support. Is support included with the licensing of the solution, and if so how long? The open source vendors will normally offer forum support for free, but it can be unreliable. If you want more than forum support, it may require a support subscription. Identify the support costs upfront.
Before you buy a solution, contact their support. If they offer phone support, call them and see if you can get someone on the phone in a timely manner. Email their support and see how long it takes for the support people to respond. This can be a good indication of what their support will be like after the purchase.
If the vendor has an online support forum, see what is going on in the forum and determine the type, volume and criticality of issues that are occurring. The volume and criticality of technical issues that are occurring can be a good indication of how well maintained the solution is from a development perspective.
Your organization is constantly changing, as are its technical needs. Vendor solutions need to be able to quickly adapt and deliver new functionality when your organization need it. Question the vendors on their architectures and their timeframes to add functionality to their solutions. Many vendors continue to rely on decades old centralized server-based architectures where new functionality requires a complete new release, which requires full testing and quality assurance. New releases generally occur on eight to fourteen month cycles or longer. Vendors prioritize their enhancement requests based on customer and the revenue, and there is no guarantee that your enhancement requests will be included.
Question the vendor regarding their architectures and how new functionality is introduced to their solutions. What is their process for selecting new enhancements? Be on the lookout for those vendors whose solutions have been on the market for a few years, began with older architectures, and never deviated away from them. These architectures are generally difficult to enhance and maintain. You can spot these older architectures by reading the installation and upgrade manuals. The installs for these older architectures will be complex and involve many steps.
About the Author:
Lance Edelman is a technology professional with 25+ years of experience in enterprise software, security, document management and network management. He is co-founder and CEO at Vallum Software and currently lives in Atlanta, GA.