This article is more than 1 year old
Is tech monitoring software still worth talking about?
Long-ignored issue, or solved problem?
Sysadmin Blog It's 2016, and the number one complaint I hear from sysadmins is still about monitoring software. The complaints have evolved with time, and every organization seems to have its own challenges. Despite this, monitoring software seems to be one of the most universal frustrations in modern IT.
In the small business world, simply having monitoring software at all is a challenge. Monitoring software is quite expensive when you're looking at SMB budgets, and the open source stuff is time-consuming and miserable to use. SMBs tend to lack training in the use of monitoring tools and also tend to have disparate software and hardware solutions, few of which are directly supported by any of the monitoring solutions out there.
The midmarket loves its appliances. Everything is an appliance. Physical appliances, virtual appliances; midmarket IT is about lashing together pre-canned goodies and making sure that A talks to B talks to N talks to Z. Midmarket companies can afford the cost of paid monitoring solutions, but the most frequent complaint here is lack of support from the monitoring software vendor.
Enterprise admins don't complain about the cost of monitoring products, and most of the software and hardware solutions they use are supported out of the box. When they need support for something added, monitoring vendors jump to. Enterprise complaints focus on practical issues: ease of use of the management interface, floods of useless or contextless alerts, or issues around automation.
You build for me, I won't build for you
Paid or not, monitoring vendors don't seem interested in dedicating staff to hardware, software, or operating systems out of the box unless some very large customers request it. Their attitude is generally that vendors and/or "the community" should build the plug-ins, scripts, cards or what-have-you to support what's out there.
Of course, not all companies have the skills required to write the bits necessary to support what's needed. If someone else hasn't written it, what can they do? Few monitoring vendors have an officially supported bounty program to get application or gadget support added, few vendors are willing to put developer time into supporting all monitoring packages, and waiting on "the community" to volunteer time isn't going to help much with rare or industry-specific packages.
The end result is that almost all small businesses have terrible (or non-existant) monitoring and most midmarket organizations have incomplete monitoring. Increasingly, I am hearing the lack of monitoring being discussed as a barrier to adoption of automation, and a serious driver for moving workloads into the public cloud.
Where enterprises cross over with smaller IT organizations is in viewing monitoring issues as a barrier to automation. The current move towards containers, virtual appliances, DevOps and other buzzwords is all part of a larger movement towards IT automation.
Instead of manually installing an operating system, an application, configuring both, loading data, and then setting up monitoring, the goal is to define a desired state configuration and trigger all the above automatically. This means that if for whatever reason a workload's environment needs to be rebuilt, it can be done at the push of a button. Unfortunately, monitoring solutions seem to be a big problem here. Some require agents, some don't. Most require some form of registration with the monitoring software. Some solutions offer APIs to script against, but there aren't really any standards, and enterprises often have more than one monitoring package, often different solutions for different teams.
Some sysadmins have reported that the time it takes them to craft the monitoring portion of the automation can take up to half of the time required to prepare the workload. Others say that even when automation of the workload package is simple, they have to manually go into the monitoring software's management interface and configure muting of alerts on a per-workload basis or their inboxes will overflow with irrelevant trash.