DIY Monitoring Tool – Pros and Cons

Part 4 of the Do It Yourself Database Monitoring Series

 

You might think that I am trying to promote building your own monitoring tool(s) in this series of articles.  Well, this really isn’t the case.  Large environments quite often build processes and scripts for specific monitoring needs.  It is almost unavoidable.   I believe I have a solid architecture to create a robust and empowering tool.  My intent is to share that architecture and how I ended up there.  With that being said, let’s go over some specific benefits and issues with creating your own monitoring solution.

 The good,

  • Learning – This is a two-fold benefit. It offers an opportunity to become more familiar with the database environment.  Also gives a reason to dig into system tables/views along with the RDBMS.  This is a win for everyone.
  • Control over what is being monitored – You know what you need and won’t you do not need. The solution can be tailored to your environment.
  • Flexibility - This is similar to having control over what is being monitored with the addition of things such as skipping certain databases, how alerts are sent, retention of the collected metrics, etc. 
  • Changes and enhancements – Need to modify the code and scripts. No need to send a request to a vendor. 
  • No licensing fees.
  • Support is in house – The subject matter experts are readily available. If there is a problem the people who created it are at hand to fix it.

 

the bad,

  • Time – It takes time to develop, test, and deploy. There is a cost here and needs to be recognized. 
  • Decisions – May seem simple to decide what you want to monitor and what you want to do with the data, but put 5 people in a room together to make this decision and you may find that it is a challeng.
  • Changes and enhancements – This takes time too. Might break something as well.  A third party vendor does this for you.
  • Schema drift – Some DIY solutions require code to be installed on every server/instance. For example, a stored procedure to check database space.  This stored procedure may be on 80 instances.  Over time it could be different across the enterprise.  Making support difficult.

 

and the ugly.

  • Quality control – Is the correct information being monitored? Is it what you think it is?  Who is going to verify the monitoring is correct?  We don’t know what we don’t know sometimes.
  • Future support - The tool will need documentation for future support.  If only a few people understand how it works then they become a point of failure for the tool.   The programming languages need to be considered too.  Should be as simple and easy to understand as possible.
  • Capabilities of peers – Let’s be honest here. Not everyone can build a tool.  Some are great at using the tools handed to them.  Creating one is different.
0
0
0
s2sdefault