Open Source Monitoring: 4 Key Questions You Need to Ask

By Ken Vanderweel 2

open-source-question-mark

Perhaps more than any other single technology, monitoring is a key contributor in the way the MSP services its clients. Monitoring capabilities play a vital role in how proactively an MSP’s staff can manage the infrastructure, how effectively they can be kept apprised of issues, and how quickly they can respond in terms of identifying and rectifying issues. Further, monitoring can be an enabler or a hindrance for MSPs looking to add new services and serve new clients—and in whether these new services can be delivered profitably. Consequently, monitoring can play a key role in an MSP’s competitive position.

Before an MSP goes down the path of using an open source product for these critical capabilities, I’d suggest they first ask four key questions:

1. Who will be the support organization?

When evaluating a short list of alternatives, it is important to understand who will be doing the support if any issues arise with the monitoring platform. When it comes to supporting their clients, MSPs need to respond as if their hair’s on fire if there’s an issue; MSPs would be well served by seeking vendors with that same mindset. Is an open source community going to share that commitment if you need help on a critical issue? Don’t bet on it. In this scenario, the MSP has to be very clear: while the open source community can be a useful resource, when it comes to following up and addressing mission-critical customer issues, the MSP is going be the support organization. That’s the only way they can ensure the level of service they need to provide clients.

Or, if you are considering purchasing an open source product from a vendor, it is important to understand what kind of support that vendor will offer. Clearly, this is an issue that’s bigger than simply deciding between open source and a commercial offering. There are plenty of commercial vendors that don’t deliver the level of support MSPs need. That’s why it’s important to speak with peers, and do a lot of research to really understand what happens if a monitoring platform goes down.

Customers expect a high level of responsiveness and consistency from their service providers when critical issues arise, as hours or even minutes of downtime can result in breached SLAs and lost business—both for the customer and the MSP. MSPs need to expect the same level of support commitment from their monitoring supplier.

2. What kind of scalability and monitoring sophistication is delivered?

Most MSPs I’ve worked with say they’re looking to not only expand the number of customers they serve, but at the same time they’re looking to sell into larger businesses. This can mean scaling from monitoring five servers for one client to 50 or more, and potentially hundreds to thousands of technologies across a collective client base.  Can the open source alternative in question scale to handle tens of thousands of concurrent events? Can you affordably and efficiently set up monitoring for dozens to hundreds of servers as quickly as a new client demands—and then efficiently monitor these resources on an ongoing basis?

A high scale environment calls for a sophisticated monitoring tool that fosters efficient operations. MSPs need monitoring solutions that enable composite SLA definitions, and that predict breaches so MSPs can prevent costly violations. MSPs also need the sophistication to gain the historical perspectives required to observe and demonstrate continued SLA compliance.  Finally, MSPs require a tool that performs automated, high-powered event processing capabilities that help prioritize operational efforts and aid in remediation. As an MSP seeks to grow, scalability and sophistication becomes an increasingly critical differentiator.

3. Do you want your engineers focused on developing and maintaining products or supporting customers?

While an open source product may meet the immediate needs of clients, what happens if a client needs help monitoring a virtualized or cloud computing environment? How about networks and unified communications?  Or end user response and deep analysis for the myriad business applications that clients adopt? If the selected open source offering doesn’t provide the required coverage initially, who will develop it?

Let’s face it, like any organization, MSPs have limited internal resources. If you look at the time your engineers have during a given week, how much is free? I’ll bet the answer is pretty much none. If you need an open source product to gain expanded functionality, it will largely fall to your organization to make it happen. Where will the time come from if they need to start supporting and enhancing an open source monitoring product? Ultimately, an MSP has to decide if they’re willing to reallocate engineers’ time from support of customers to support of open source projects.

4. Do limited management interfaces negate upfront cost savings?

For many MSPs, open source alternatives work fine initially, and represent a minimal upfront investment. What often happens however, is that, as the MSP’s business grows over time, and the size and complexity of customer accounts increases, open source alternatives start to be very cumbersome.

Many open source products lack a robust management interface, which means a lot of custom coding, a lot of time dedicated to management and maintenance, and an increasing distraction for staff from the MSP’s core business objectives. Time is money, and having staff handling the development and maintenance of their own scripts has a direct, ongoing cost that MSPs need to factor in. There’s also significant business risk in having one internal developer writing a bunch of custom code: what happens if that engineer walks? Further, because of the limited capabilities of open source, MSPs can suffer significant costs in terms of lost opportunities because it’s difficult to add new services and pursue new accounts. As a result, the upfront savings of open source often start to look pretty meager, or evaporate completely, over time.

Conclusion

Ultimately, MSPs need to look at their DNA. Are they a product development organization or a service organization? I’d argue it’s very hard to be both. Can the MSP afford the cost and distraction of developing, maintaining, and supporting an open source monitoring product internally?

In addition, MSPs need to look at the DNA of the open source products available. Do they have the makeup to be an enterprise-grade solution that enables, rather than hinders, an MSP’s growth objectives? Is it in their DNA to move elegantly beyond being a tactical, low-cost point solution to one that yields real business advantage in a competitive MSP market?

Possibly the worst outcome for an MSP is that they dedicate the time and resources to configuring and maintaining an open source alternative, only to abandon it when they run into a wall. That’s why it’s critical to ask some of these hard questions earlier rather than later.

Ken Vanderweel is director of product marketing for Nimsoft. Guest blog entries such as this one are contributed on a monthly basis as part of MSPmentor.net’s 2009 Platinum sponsorship.