Free Monitoring Solutions: No Throat to Choke

Seems obvious, but one of the greatest drawbacks of free monitoring solutions is that you (mostly) need to support them internally.

Obviously, that means if the monitoring falls over, you need to set it upright. And considering that monitoring is a cornerstone of business continuity, that’s a big responsibility. If your monitoring solution is open source based, of course, you can frequently find community sources of advice and information. But as we’ve noted previously in this series, that help can be of limited practical utility in an emergency.

Unsurprisingly, IRC channels and the comment threads of GitHub repos don’t guarantee responsiveness (though they can be surprisingly responsive). More important -- however knowledgeable responders might be about core components of your free monitoring setup, they can’t know the specifics of your implementation, and are relatively unlikely to know all the third-party components you may have integrated with it. So their ability to quickly determine the root cause of issues and provide recipes for solving common problems is likely very limited -- highly dependent for success on your knowledge of how your special snowflake implementation works (which may or may not be comprehensive -- perhaps you inherited the solution from a predecessor?) and on your mastery of forensics (because of course, you can’t let strangers log into your system to poke around).

But help with emergent system failures is just one small part of what you’re missing in the absence of comprehensive support. Here are some others:

Opinionated, complete, rapidly-deployable, scale-ready solution. The best monitoring vendors want their customers to succeed, which means getting the solution deployed, stabilized, configured, and delivering value in as short a time as possible. Naturally, vendors also want to limit the time and expertise required in initial customer engagements (because time is money for them, too). So they design and build their software and tooling, and they accumulate and document best-practice in order to make this possible. Deployment is automated. Discovery and data ingestion is automated. Monitoring standard stuff is point-and-click. Monitoring complicated stuff might involve some research and coding, but it’s a constrained problem bracketed by known quantities. This commonly saves months of your time at outset (and potentially tens to hundreds of thousands of USD$ in opportunity costs).

What “one throat to choke” can really mean. Committed support doesn’t just mean “there’s someone you can call.” Mature customer success organizations typically assign technical account managers (TAMs) to each enterprise account -- so there’s a real person there to help you. Your TAM will typically be able to escalate problems quickly to several tiers of expert, from implementation engineers with broad experience making the product work for real customers at scale, to application engineers intimately familiar with solution internals.

But that’s not all: your supporting vendor should even be able to take your side and escalate to third parties when that’s called-for: be these open source communities (in which your solution vendor may participate actively) or vendors of companion products (with whom your solution vendor may have partnering and collaborative support agreements in place to quickly solve dependency-related issues).

Training, community, and other benefits. A mature monitoring platform customer success organization doesn’t just deploy, configure, validate, and then stand by waiting to respond in crisis. Monitoring is way too complicated, and way too intimately connected with customer IT processes not to take a more proactive approach. Support agreements often include serious, in-depth (i.e., multi-day, on-site or remote) operator training and periodic customer success meetings, helping ensure that your team can get best value from the product over time. Other valuable perks may include invitations to join and share knowledge with your vendor’s customer community via local MeetUps and conferences.

Access to, and influence over the product roadmap. Finally, a customer relationship with a supportive vendor will include a seat at the product planning table, advance notice of upgrades, and serious consideration of your new-feature requests by developers. We’ll talk about this more in our next blog.