There are 2 common approaches to database monitoring: server-based and client-based. There is a third option: monitoring the connection using a database proxy.
Join the DZone community and get the full member experience. Sometimes you just need to know what a database client is doing in the database. You might be: By database client, we mean anything that talks directly to a database: it might be a middle-tier running in an app server, a report writer, a spreadsheet in Excel, a web app written in PHP, a lambda function in the cloud, and so on. Whatever the reason, getting visibility into a client’s database interactions is hugely helpful to understanding that client’s behavior. Generally speaking, there are two common approaches: server-based and client-based. There is also a third option, which is less commonly used: monitoring database connections. This is the middle way: it focuses neither on the database servers, nor on the database clients, but rather on the connection between them. Let’s examine the advantages and disadvantages of the more common solutions, and see what this third way brings to the table. Most enterprise databases have built-in monitoring capabilities. If you have admin-level access to the database, this type of monitoring might be a good solution, but it may not always be easy to use if there is more than one client accessing the database. Server-side monitoring is preferred by people who view the world mostly from the perspective of the database, since this type of monitoring gives you full access to everything happening in the database server: CPU and memory, network and disk usage, deadlocks, etc. The main disadvantages of this type of solution are: The solutions focusing on the database clients require you to install an agent in the client(s).
