I urge you to, just for the fun of it, give mycheckpoint a try. I think you’ll be surprised at the depth and detail one can fit within such a small footprint, in one python script.

I’m not belittling other monitoring tools, of course. I can’t compare mycheckpoint to cacti, they’re on a completely different scale. I’m just saying. Try it.

A couple of years ago, I looked at that and said yuck to that. I looked at key-value stores, but that performs terribly at scale. Instead, I stuffed the values into a JSON structure in a single column. Then the scripts can either do a json_decode, or a fairly simple regexp to reach into the JSON.

So, I currently have a provide the expression, the host(s) desired, timeframe, etc, and PHP does all the grunt work. It performs quite adequately.

I don’t need a WHERE clause on the status/variables.

Since I deal with hundreds of servers, from 4.0 to 5.1, and Percona, this mechanism does not care about new names. (Name changes like “table_cache” vs “table_open_cache” are a nuisance.)

I have already been using it with the user_statistics patch to see trends in some of my top tables.
I guess I could also monitor mycheckpoint data itself to get more info from it, should I choose to.

I think it makes sense that 3 tools that do different things approach the problem in 3 different ways:

– The Percona Nagios plugin set is not concerned with caching, because it does not reuse any of the information it retrieves, it only uses the information once.

– The PalominoDB Nagios plugin caches because the same plugin can be used over and over to check different calculations of variables, and is designed so that the check could be run efficiently within a check interval. Ironically it was designed this way because of the benefits realized from the MySQL Cacti Templates.

– mycheckpoint stores because the data is used for graphing, but can also be used for alerting. In a way this is like cacti itself – it stores the data for graphing, and can also be used for alerting.

I made my post because I was worried folks would think “caching for monitoring is bad” – Baron specifically said that the Percona plugins are run infrequently, but I know there are many folks out there that would quickly turn his post into a “caching for monitoring is bad” myth.

1) Everytime MONyog sends a statement like SHOW VARIABLES/STATUS of some kind (or fetching a OS metric from Linux /proc folder) one row is INSERTED into [timestamp_master] table with information about current time and the metrics retrieved for each such statement will be INSERTED into [snapshot_master]. The [snapshot_master] table contains the metrics details.

2) And actually we do not always INSERT into [snapshot_master]. Only if the particular metric was changed since last time something was INSERTED for that metric we will INSERT again.

3) Finally note that [snapshot_master] does not have the names of the metrics. It is not possible to know in advance what metrics the server will return as it depends on server details (version and configuration). And actually a server may be upgraded.