I realized when I released my very crappy version of My ‘hourly’ MySQL monitor script I really should have included my standard logging.
So I did that the night I wrote my original blog, but never published it. I’ve had need to use it again today, so a few more usability tweaks for parameterization and we are good to go.
Now Version 0.03 includes three files:
Simple use is:
$ cd /directory $ vi mysql.conf # correctly specify MYSQL_AUTHENTICATION $ chmod +x ./hourly.sh $ nohup hourly.sh &
This gives you the following files
-rw-r--r-- 1 rbradford rbradford 2643 2007-05-29 15:47 mysql.innodbstatus.070529.154757.log -rw-r--r-- 1 rbradford rbradford 414 2007-05-29 15:47 mysql.processlist.070529.154757.log -rw-r--r-- 1 rbradford rbradford 12597 2007-05-29 15:47 mysql.status.070529.154757.log -rw-r--r-- 1 rbradford rbradford 22229 2007-05-29 15:47 mysql.variables.070529.154757.log -rw-r--r-- 1 rbradford rbradford 13146 2007-05-29 15:47 os.ps.070529.154757.log -rw-r--r-- 1 rbradford rbradford 390 2007-05-29 15:48 os.vmstat.5.070529.154757.log
By default, written in /tmp, you can override by setting LOG_DIR.
It gives you a pile of output you can easily grep, I’m working on some very simple graphing. One thing I have done is pass the status into Mark Leith’s Aggregating SHOW STATUS Output as well as passed on some feedback that I hope will get integrated into later solutions.
For now, it’s a tool I can implement in a few seconds, run while somebody is showing or demonstrating a system, and I’ve got some meaningful information to look at. Combined with my more in-depth ‘minute’ script, a general-log and taking notes of individual steps in a system walk though, I have all the information I need to analyze a working system very quickly from a purely database level. Still there is lots to do manually, but I’ve got a consistent view of information to review.