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
  • FormerMember
    FormerMember

    Ah, good old tool sprawl.

    I've been part of a push to standardize on a single set of monitoring tools (Solarwinds) from a multitude of separate systems.  Right now we have HP OpenView, GFI Server Monitor, Solarwinds, and Zenoss.  Each monitors its own set of systems, and reports back to the appropriate team.  Unfortunately, the push toward Solarwinds as a single pane of glass has been difficult at best.  See, the HP-UX teams don't want to expose their systems to Solarwinds, because it would mean giving access to data they like to keep in-house.  Additionally, that team doesn't want to give a non HP-UX admin (me) credentials to pull data from their boxes.  Our server team purchased a SLX license for SAM, and has added most of their servers to monitoring, but hasn't tuned it to function and give the same detail that GFI does.  Because it doesn't work 'the same' they don't use it... meaning GFI is still chugging along. 

    Finally we have Zenoss.  This one is odd because it was set up by an old Linux admin who doesn't work for the company anymore.  Nobody knows how to admin it, but it works to update data into their documentation wiki, so it stays running.  At some point it's probably going to die from not being maintained, and the team that uses its data will have to figure out a way to get it from somewhere else. 

    So, to answer the actual question, yes, we're trying to prevent tool sprawl.  Mostly in an effort to get our helpdesk and NOC teams setup with ability to see issues as soon as they arise, without having to log into 4 different systems. 

Comment
  • FormerMember
    FormerMember

    Ah, good old tool sprawl.

    I've been part of a push to standardize on a single set of monitoring tools (Solarwinds) from a multitude of separate systems.  Right now we have HP OpenView, GFI Server Monitor, Solarwinds, and Zenoss.  Each monitors its own set of systems, and reports back to the appropriate team.  Unfortunately, the push toward Solarwinds as a single pane of glass has been difficult at best.  See, the HP-UX teams don't want to expose their systems to Solarwinds, because it would mean giving access to data they like to keep in-house.  Additionally, that team doesn't want to give a non HP-UX admin (me) credentials to pull data from their boxes.  Our server team purchased a SLX license for SAM, and has added most of their servers to monitoring, but hasn't tuned it to function and give the same detail that GFI does.  Because it doesn't work 'the same' they don't use it... meaning GFI is still chugging along. 

    Finally we have Zenoss.  This one is odd because it was set up by an old Linux admin who doesn't work for the company anymore.  Nobody knows how to admin it, but it works to update data into their documentation wiki, so it stays running.  At some point it's probably going to die from not being maintained, and the team that uses its data will have to figure out a way to get it from somewhere else. 

    So, to answer the actual question, yes, we're trying to prevent tool sprawl.  Mostly in an effort to get our helpdesk and NOC teams setup with ability to see issues as soon as they arise, without having to log into 4 different systems. 

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