MySQL Enterprise Monitor: The Secret about Agents

I am often asked why we chose a distributed, web-based architecture for the Enterprise Monitor application. For those not familiar with how the app is deployed, the Enterprise Monitor is typically installed within a customer firewall and is comprised of 3 components:

- a lightweight agent written in C, that is deployed to each monitored server to collect MySQL, OS data and Query content and diagnostics
- a centralized server that monitors the collected data and queries, sends out alerts and serves up the supporting web application
- a MySQL repository that holds the collected data and queries

A typical deployment looks something like this:



Having come to MySQL from Embarcadero Technologies, I understand that many customers are somewhat uneasy with loading an agent on their production database servers. In fact for environments with a small number of developers, applications, and databases I actually prefer a client-centric solution. With this in mind I use the following guidelines when deciding if a new administration/monitoring product or app should be client or web-based (please note that these do NOT apply to development or design tools, which are best rendered in client side apps):

Local, client-based apps are best for:
- Small development shops (3 or less developers). I want the available connections to my production servers to be paying customers not DBAs or Developers!
- Small applications with a small number of MySQL servers. Most client side apps provide single server connections and visibility making navigation a bit kludgy. Some ISVs have the multi-server view thing figured out, but most do not.
- Departmental applications with limited end users. The SLAs tend to be less strict and network bandwidth issues around pulling data to/from dedicated client connections is less of an issue.
- Small, localized corporate campuses. Typically client based solutions require the footprint of the app to reside on a specific desktop, device, etc. This requires the user to be somewhere close to an enabled workstation to well, uh, use the app.

Distributed, web-base apps are best for:
- Large shops with many DBAs, Developers, Sys Admins. In most web-based deployments all app users can be serviced by a single connection and data collected by an agent that is running on the monitored data source. Minimal connections, maximum efficiency.
- Monitoring and managing a large number of backend MySQL servers. This is made easy because typically an agent based architecture scales better than one that relies on adding more clients (and connections) to an environment. Most deployed agents serve as "daemons" that keep track of things MySQL up/down status, connection status, etc, all without the user having to initiate a connection.
- Monitoring MySQL from anywhere. Basically all you need is access to a browser. Enough said.

So, why did we choose a web-based architecture for the Enterprise Monitor? Well, it seems most of our users are split across these guidelines; most have small, nimble MySQL DBA and Dev teams, but an ever growing number of MySQL servers. We opted to provide a tool that would help them scale their resources to monitor/manage more MySQL servers with less time and effort.