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.
Introduction:
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?
The answer is YES, and it is very simply to do actually. Say you monitor 2 servers that you in MONyog have named "Testserver" and "Production" respectively, and that you want a CRITICAL setting of "90" for "Testserver" and "80" for "Production". Then the CRITICAL setting is not a constant (applying for all MySQL servers) anymore, but a condition needs to be added. MONyog exposes connection details to different MySQL servers monitored as Javascript objects that can be referenced with a simple if/case-condition. And it is very simple to work with. Just replace the constant with a (javascript-)function like this
function()
{
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)
Update as per April 5th 2012: From MONyog version 5.11 you can also use server tags in scripting. MONyog 5.11 release notes say: * Introduced tag level customization in MONyog Monitors. MONyog tags for servers are now available as MONyog Object Model variable (MONyog.Connections.TagName returns an array of tag names defined for a server). Documentation has examples on how to use it in scripting. Also see the note on ‘Native Javascript properties’ support in next point below. * Native Javascript properties (like length, indexOf, splice etc) are now fully supported in Monitors and Dashboard. Note that ‘indexOf’ is required to extract individual tags from the array exposed by MONyog.Connections.TagName (see point above) in case there is more than one tag. Since (quote) "MONyog.Connections.TagName returns an array of tag names" you cannot use the "=" operator when checking if a server is registered with a specific tag because a condition of the type "if (string = array).." will not work in Javascript (unless there is only one TAG for a server). Instead the syntax to use in the condition is "if(MONyog.Connections.TagName.indexOf("SomeTag") >=0 ) .. ". "indexOf" will return "0" for a server not registered with the tag "SomeTag" and else a higher value.
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