Monitoring MySQL with MONyog

It just works. In absence of any MySQL monitoring for your site, I have found no solution that gets you operational as quickly and easily. MONyog can be deployed in 60 seconds, and configured in another 60 seconds. Within 5 minutes you can have visual monitoring of your MySQL environment.

MONyog is an agentless process, which is an advantage for easy install, but does not provide for monitoring redundancy in the capture of information due to agentless nature. It’s a static standalone executable which is great if you need something to work out of the box. You can easily configure multiple servers in a replication topology, or different servers in your environment. You get the ability to monitor all the usual information, with a dashboard and detailed graphs. While MONyog does provide customizations of rules for the graphs and presentation order, that’s about it. You can’t at this time for example change the colors, what’s on graphs except for what MONyog monitors or the security of certain options in the GUI to different users, however I hope they offer these suggestions in future releases.

MONyog includes some nice features that are overlooked in other products. You have the ability to monitor the MySQL error log (if configured appropriately) which is a common complaint of end users. You can also see the process list, and when configured you can also perform query gathering and analysis.

MONyog is a well priced commercial product with a free trial download without registration requirements which gives no barrier to access and evaluate. As a solution and ease of deployment, there is no excuse not to evaluate this product. If you have no monitoring, you can now quickly and easily. I find a number of clients that simply have no monitoring. There really is no excuse as it’s critical information you need to have and record for a successful business.

You can get it from


  1. ronald says


    An agent process can collate information on servers, and hold this information, sending to a central server if this is unavailable for any reason.

    With the agentless process, any interruption of the central server,causes that time slice of data to be lost, and it can not be re-created or collected.

    This is a general architectural consideration, not a specific MONyog limitation. It’s a tradeoff that affects features, installation,management etc.

    The one option in an agentless process, is to duplicate your monitoring servers, to support this, however this causes double load on monitored servers, some consider that unnecessary, but again a trade off.

    I trust that answers your inquiry.

  2. says

    This is of course true. However what is the situation with agent-based monitoring tools? In case the agent cannot communicate collected data to its master, what will happen? Will if simply drop the data? Will it store it? Where (in memory, in a database)? For how long will the agent be able to be disconnected from its master and still be able to update everything when connection is available? All that depends on the implementation of course and settings may be available as well. I do no claim to know such details about other monitoring tools.

    No matter what, we never had any problem reports with this till now. Probably connectivity to servers is not an important issue in practical life with today’s standards or networking. Also if server is disconnected there will be little or no activity on the server to monitor. A remote monitoring tool may of course be disconnected as well and there we have the (theoretical) issue. But in our experience it is no issue for users in practical life. If it is a problem sometimes, you may simply install MONyog on the same machine as MySQL (if hosting details allows for it).