Please note that this blog was updated on April 5th 2012. We have added(at the buttom) how to use server TAGS for defining thresholds.
If you have been using MONyog you will know that any metrics/counters may be identified with either of the ‘states’ STABLE, WARNING and CRITICAL. For those metric where it is relevant MONyog ships with settings for this that are (to the extend possible) commonly agreed ‘best practices’ by MySQL DBA’s. Metrics in a WARNING or CRITICAL state display with a (yellow or red) ‘marker’ indicating that this metric is not in a STABLE state. For metrics in a CRITICAL state further an alert can be sent (as a mail alert and/or a SNMP trap).
If the ‘best practices’ we have implemented in MONyog do not fit your environment or use case, it can easily be customized. Open the MONyog ‘Monitors/Advisor’ page, click on the name of the metric you want to adjust (it is a link). A small popup opens. As an example let us take the ‘Connection usage’ in the ‘Current connections’ group. In the popup you will see the settings for this metric. They are defined like this
Warning = 75
Critical = 85
To change the settings click ‘Customize’ in the popup and next ‘View Advanced’ to see all options. It will open in a new browser tab. If you are willing to allow the number of current connection to reach 90% of the max_connections allowed before the state should change to CRITICAL just enter “90” as the value for the threshold of the CRITICAL state and save.
Differentiating thresholds for different MySQL servers:
What we described above will have effect for all MySQL servers monitored. It was also meant to be an introduction only. The real question to be dealt with here is different however: Is it possible to have different ‘state’ settings for different MySQL servers?
if(MONyog.Connections.ConnectionName == “Testserver”) return 90;
if(MONyog.Connections.ConnectionName == “Production”) return 80;
Below a (reduced) screenshot of values entered in the customizations page:
.. and now save. That is all. Now the CRITICAL condition for this metric is defined differently for the MySQL servers “Testserver” and “Production”.
Note that everything happens centrally at the MONyog level and there is nothing to do on the MySQL servers monitored. And also there is no need for any other program or utility (such as a database client or whatever) to do this. MONyog is agent-less and self-contained.
The objects that can be referenced in the customization interface are listed in the MONyog documentation here along with the explanation of the ‘MONyog Object Model’: http://www.webyog.com/doc/MONyog/MONyog_object_model.htm
In the above image we have defined different WARNING and CRITICAL values for another metric (‘percentage of max_allowed reached’ in the ‘Connection history’ group) for two servers: For both servers WARNING is set at 84% and CRITICAL at “Testserver” is set at at 90% and at “Production” CRITICAL is set at 87%. You will notice the red and yellow ‘markers’ displaying accordingly.
(There is one more detail you should be aware of: MONyog will not necessarily alert using mail or SNMP first time a CRITICAL value has been reached. There is a setting for this as well. The default setting is that the CRITICAL condition must have been in existence for 5 consecutive data retrievals from MySQL. This setting is specific for every MySQL server registered in MONyog and is available in the MONyog ‘Register servers’ page for each server, but the value can be overridden for an individual metric by setting the “RetryOverride” value from the customizations page. Please be aware of this when testing or you may become confused why you don’t get the alerts you’d expect)
Download the MONyog whitepaper: http://www.webyog.com/en/whitepapers/MONyogWhitePaper.pdf
Read the MONyog documentation online: http://www.webyog.com/doc/index.php
Download MONyog TRIAL: http://webyog.com/en/downloads.php
Purchase MONyog: http://webyog.com/en/buy.php