About the Author:
Lukas Vileikis is an ethical hacker and a frequent conference speaker.
Since 2014, Lukas has found and responsibly disclosed security flaws in some of the most visited websites in Lithuania.
He runs one of the biggest & fastest data breach search engines in the world -
BreachDirectory.com, frequently speaks at conferences and blogs in multiple places including
his blog over at lukasvileikis.com.
If you have ever worked with databases or if you have ever found yourself in a DBA role of some sort, you have probably noticed that the monitoring of your database instances is not a very easy task. As the monitoring of your database instances required more and more resources, you have probably already switched to a database monitoring tool which might be helping you solve database related issues. Here’s a catch though – this poses one significant problem: if the monitoring of your database instances is locked in to a specific vendor, you have got a pretty big problem on your hands.
Why is Being Locked in to a Specific Vendor Bad?
Don’t get it wrong – the monitoring of your database instances might already be a habit for you – and a very good one at that. We are talking about scenarios where you have already chosen a monitoring tool for your database instances and you might have noticed that the database instance monitoring tool is only able to monitor a specific part of your database farm (for example, the tool might only be able to monitor PostgreSQL and Sybase database instances, but you might find yourself frequently using MySQL) What then? What can you do to solve this problem? Fear not, dbWatch has a solution.
How can dbWatch Solve This Problem?
If you find yourself using a tool that is locked in to a specific vendor, dbWatch can be a very good tool to help you get rid of this problem. dbWatch is a highly scalable software solution that can help you monitor any number of database server instances safely and effectively while also providing you control over all aspects of operation, performance and resource usage. The tools developed by dbWatch (for example, the ControlCenter which we will cover in a second), are not locked in to a specific database vendor meaning that whatever database instance you run – doesn’t matter if it is MSSQL, Oracle, PostgreSQL, Sybase, MySQL or Azure SQL – dbWatch can assist you. The tools developed by dbWatch (we are referring to the Control Center) can solve pretty much any database issue you encounter: the dbWatch jobs (they help solve problems and can be called the “backbone” of dbWatch as a whole) range from jobs that can help you check the uptime of your database instances to jobs that can show the hit rate of your query cache. dbWatch jobs can also help you see the aggregated or detailed growth rate of your databases, can help you check your database load, check the efficiency of the InnoDB buffer pool for InnoDB or the key buffer for MyISAM (if you are using MySQL), analyze the memory setup of your database server(s) or provide information about their load, it can help you check if tables with different collations are defined on the instance and database level and so on.
For example, here’s how dbWatch job section looks like (to see this window, right click on a database instance you use and click “Configure Jobs”):
Also bear in mind the fact that the jobs you see above are only related to MySQL (if you use other database instances, you will probably see different results) and that the dbWatch jobs are scattered across multiple categories (look into the image above: you will see an “Availability” category, a “Capacity” category and a “Performance” category meaning that the jobs that accomplish related functions will be there)
Besides the dbWatch jobs, here’s how dbWatch looks as a whole when it’s up and running:
We would like to direct your attention to a couple of important aspects of the user interface of dbWatch: observe the “Jobs status” section, the “Jobs” section, the “Instance Information” section and the job status section. You will clearly see that the “Instance Information” section for example lists all of the database instances connected with dbWatch. What does that mean? That means exactly what you think it does – you are not locked in to a specific vendor when using this tool! If your database instances consist of a mix of MSSQL, Oracle, PostgreSQL, Sybase, MySQL and Azure SQL, you are in good hands: you will see all of them listed below. dbWatch will not only list them – it will allow you to perform a set of actions on each one of them (you can run different jobs on each one of them if you so desire) meaning that you can monitor all of them in one go using one tool. Isn’t that convenient?
Checking the Status of Database Jobs
As far as dbWatch jobs are concerned, these can be observed at the left side of dbWatch. Take a look:
The dbWatch jobs can have multiple status codes – an OK status code meaning that the job ran successfully, a Warning status code meaning that the job encountered some sorts of errors on the way or an Alarm status code meaning that the job either didn’t complete or ran into a major issue that needs resolution.
Above the list of categorized jobs you will also see a pie that represents the status codes of jobs together with their amount (in this case, OK (2) means that two jobs have a status of OK) – this “pie” can help you determine the overall health of your database by the status of jobs that have already been completed.
All dbWatch jobs also have a configuration section and a details section, they also can be scheduled and disabled or enabled. For example, here’s what you will see after you right click on a job:
This is another major feature of dbWatch – aside from freeing you from a specific database vendor and instead allowing you to monitor all kinds of database instances at once, dbWatch also allows you to explore every job in detail and configure it. For example, here’s how the collation checking job for MySQL looks like in detail:
This job displays the collation types and databases with multiple collations helping you decide how to further optimize your database instance(s) in order for your queries to run successfully. With that being said, jobs in dbWatch can also be configured. For example, this is how the InnoDB buffer pool checking job looks like when it’s being configured – you can set a hit ratio alarm threshold (dbWatch will return an alarm if the hit ratio falls below this value in percent) or a hit ratio warning threshold (dbWatch will return a warning if the hit ratio falls below this value in percent):
This blog post should give you a pretty good idea of what dbWatch can do to help you avoid being locked in to a specific database vendor – hopefully, this blog post also gave you a list of ideas of just how powerful the jobs in dbWatch can be. If you still feel that you might need some sort of a push, feel free to contact the team if you need any assistance – they will be happy to help push your database instance efficiency to the next level.