Open Source Monitoring: 4 Key Questions You Need to Ask
First, let me be clear (hopefully before I get tarred and feathered): this isn’t intended as any kind of attack on open source, whether the concept, the technology, or the business model. To do so would be to discount one of the most meaningful trends in IT over the past decade. What I’m discussing is open source within a very specific context: Managed service providers (MSPs) using open source products to monitor their clients’ and their internally hosted IT infrastructures. That’s a very different proposition than, say, using open source as part of a Web development service or adopting a LAMP stack in a hosting environment. Here’s why.
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.
Far from thinking you should be tarred and feathered, I think you’ve addressed the subject very well. I would add a couple of things…
1. Another consideration one should make is the responsiveness of an Open Source product vs. its commercial counterparts to significant changes in the technology landscape and/or marketplace. For example, if a significant shift occurs away from client-server models or to something like a cloud infrastructure, how quickly will an Open Source product adapt vs. a commercial one?
2. There may be scenarios where it’s worthwhile considering using both Open Source and commercial monitoring products together. Open Source products may offer a cost-effective alternative for less critical or very specialized systems, or where they serve a very specific purpose. In these cases, they may not create a “distraction for staff from the MSP’s core business objectives”.
Ironically, I just got off the phone with a software company that’s launching a hosted and on-premise MSP tool. The challenge: It only manages PCs, servers and mobile devices running a specific version of Linux. Sounds like a powerful tool… but only if you’ve standardized on the vendor’s Linux offering. More details next week.
[…] Before a managed service provider (MSP) goes down the path of using an open source product for critical remote monitoring capabilities, I’d suggest you first ask four key questions. Here they are. […]
I’ll second Scott and say you don’t need to be tarred and feathered. The part that I think rings most true is that with an open source solution the MSP has to be prepared to be their own support for the platform. If the MSP is staffed for it, then maybe that’s not a huge risk, but it certainly represents a HUGE business risk if you aren’t staffed to support it internally.
[…] Open Source Monitoring: 4 Key Questions You Need to Ask 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? […]
I do see the point at which the MSP has to be prepared to back up thier open source solution. I have to admit that I have used commercial versions of monitoring and found it VERY complex and “tied” down. We monitor over 200 networks ranging from Novell, Linux and Windows and found that Nagios is able to be “molded” to each certain network and give us the best monitoring available.
We use Zenoss (www.zenoss.com), an open source monitoring platform for the Enterprise and MSPs.
Initially, we did have to invest a lot of time and energy into “molding” the product to meet our needs, but we’ve also found the Zenoss team to be extremely helpful in overcoming specific client challenges. I cant say I’ve had the same experience with the traditional MSP platforms.
We’ve also found the community incredibly helpful in troubleshooting specific issues as well as co-developing monitoring sets for client devices.
I don’t think there is a product out there that is excellent across the board (monitoring, asset management, ticketing, scripting, remote control etc). Our strategy will be to continue to use what is best in class for each segment of IT management.
“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?”
FYI, the majority of our work is hosting and on premise virtualization. We selected Zenoss for its ability to monitor virtual machines…
I say tarred and feathered. Reminds me of the scientist preaching to the church saying to turn away from God and trust in science. The difference is that you’re the director of product marketing for an obvious commercial product–you’ve probably never even used an open source monitoring system.
I’ve paid thousands for a commercial MSP product and I have demoed the open source stuff. Since most of the major players are leaning toward integrating with open source what’s the holdup for Nimsoft?
“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.”
The best MSP platforms require you to write scripts. Unfortunately there is no one fix solution for all servers and/or workstations. Last but not least if you need “support” with your open source product–pay the developers for it. You’ll still save thousands.
I’m extremely interactive with chief executives across our MSP partner base, a base that’s made up of the world’s largest, most experienced, proven, and successful MSPs. Nimsoft MSP partners are 5-25+ years in practice, global presence, have significant staff and world class facilities, thousands of brand name mid- to large-enterprise clients, massive and mixed IT infrastructures under management, early adopters of emerging technologies, and more. The key questions, insights, and guidance in this blog article are practically spelled out verbatim from the personal experience of these MSP business leaders. A constant theme and inspiration to write this article is open source monitoring tools inhibiting our MSP partner’s business optimization and growth objectives. Nimsoft continues to sign on countless numbers of MSPs at rapid rate who defect from their various open source monitoring investments (as well as various commercial monitoring tools) to realize the business growth advantages of Nimsoft Monitoring Solutions, our spirit of partnership, and unmatched support.
Understand that in this article I speak for Nimsoft Monitoring Solutions contrasted against various open source monitoring tools; I am not contrasting the many other commercial monitoring tools in the marketplace (that you may have had a poor experience with) against open source monitoring tools as I do not have intimate first hand experience with those tools and MSP users.
Anyone got turpentine?!
Ken Vanderweel
Director, Product Marketing
Nimsoft, Inc.
Your article should have begun…
“first, I work for a company that sells closed source (proprietary) monitoring software”
“second, ….”
Be honest and upfront, surely these are characteristics that your business partners would expect?
I am not criticising or responding to any of the later points in your article directly, but I do feel if you are going to be very ‘anti’ something then you should declare your commercial position at the outset.