Too Many Tools

I'll make an assumption: if you're a Thwack user and you're reading this post, you've got an interest in systems and applications monitoring. Or maybe you just really want those points. Or that Jambox. Whatever's cool with me.

But if you're a tools geek, this post is for you.

Tool suites aspire to have the ability to monitor everything in your infrastructure, from hardware, through networking and virtualization, right up to the user. But to be honest, I've never seen a single solution that is capable of monitoring the entire environment. Many times this is not a technological problem; organizational structures often encourage multiple solutions to a single problem (e.g., every team purchases a different tool to monitor their systems, when a single tool (or a subset of tools) would suffice). Other times, tool sprawl is the result of staff or contractor turnover; everyone wants to bring the tools they know well with them to a new job, right?

Tool sprawl is a real problem for IT shops. The cost alone of maintaining multiple tools can be staggering. But you also run into the problem of too many tools. You'll likely end up monitoring some systems many times over, and will most certainly miss other systems because there's confusion over who is monitoring what. As a result, you'll end up with more tools than you need, and the job still won't be done.

How do you manage or prevent tool sprawl at work? Do you lean on a single vendor, like SolarWinds, to address every monitoring need that arises? Or do you seek out best-of-breed, point solutions for each monitoring need, and accept the reality that there is no single pane of glass?

Parents
  • Although I agree with the single team monitoring -- there are real instances where a single team does not make sense. In my position, having our home office monitor my local pit mesh network really does no good. I get inaccurate ping times, inaccurate up/down status and our home office is annoyed that our entire site goes down (lost link between home office and our office -- not the entire network down).

    Once we deployed NPM locally, we can really use the functionality to enhance and improve our network. Home office is no longer annoyed with nodes they have no control over, although I'm sure they would (at times) want to see our network stats.

Comment
  • Although I agree with the single team monitoring -- there are real instances where a single team does not make sense. In my position, having our home office monitor my local pit mesh network really does no good. I get inaccurate ping times, inaccurate up/down status and our home office is annoyed that our entire site goes down (lost link between home office and our office -- not the entire network down).

    Once we deployed NPM locally, we can really use the functionality to enhance and improve our network. Home office is no longer annoyed with nodes they have no control over, although I'm sure they would (at times) want to see our network stats.

Children
No Data
Thwack - Symbolize TM, R, and C