Update for all of the RSS subscribers of this site: please update your RSS feed to the new feedburner address: http://feeds.feedburner.com/Themattreid?format=xml
I’ll keep the original feed link active for a while but please change to the new one when you get a chance. Oh, why not just do it now since you’re on the internet and thinking about it, eh? It’s a good idea and a win-win situation. 
Data storage requirements for Kontrollbase [monolith] server_statistics + server_report tables. These are the tables that accept incoming data from the polling processes. They hold the historical data for each server that’s being monitored.
AVG Per Server
Assuming stats every 10 minutes = 144/day
Assuming reports every hour = 24/day
10K for one row of server_statistics: 1.44 mb
16K for one row of server_report every hour: 390K
TOTAL: 1.82M/day of data collected per server
The Monolith Toolkit of scripts for DBA routines. 0.4.3 has been released. You can download it here: http://code.google.com/p/monolith-toolkit/
Some information on the toolkit and what it contains:
Changes for this release:
I was working on a client’s server today to troubleshoot some variances between the result timing of some queries. Guess what I came across – the profiler is not available in certain enterprise releases but it is available on community versions of the same release number.
I can understand if that feature was something that wasn’t fully tested in the enterprise code base and thus was only released in the community version – but if that’s the case then I don’t understand why the same version releases of Community and Enterprise can have different feature sets. That goes against the whole idea of versioning. Someone correct me if I’m wrong here but that is very frustrating.
Update for all of those that are following the progress of Monolith. I’ve been busy this week coding the reporting engine – the code that analyses the hundreds of variables that are being collected – and I’m pleased to say that Perl was the correct choice for this application.Installation on the client servers will be a breeze, and relatively few non-standard modules are required for the server application.
I’ve been silently wondering for some time if the reporting engine equations should be part of a pluggable system (stored in the database) or if they should be hard coded. After writing up all of the equations, I’ve come to the conclusion that, for a quicker release, the equations and reporting engine will be hard-coded this time around for the default system alerts. Howeve -> user-defined alerts will be pluggable. Revisions ahead of 2.0 might feature pluggable main equations but I want v2.0 out asap.
Second bit of news on the application is that any users that were requesting a simple web-based install with a single config file have now gotten their wish. It’s a much streamlined process this time around.
And the final news is that I have decided to change the name of Monolith. There’s an app on the MySQL site that is from the Monolith company and it does monitoring along the lines of Zenoss – as in site wide monitoring that isn’t MySQL specific like my software. As such, to keep the projects easier to differentiate – my Monolith app will be released under the name of Kontrollbase. Kontroll is Swedish for control, and seeing as MySQL is originally Swedish and that the app helps you control the performance of MySQL… there it is. So, from now on Monolith will be referred to as Kontrollbase.
Things are looking up for release 2 and it’s coming along with good speed. More later… back to coding.
Monolith: MySQL server monitoring. I only have servers that run Redhat/Debian/Ubuntu Linux x86 and x86_64. I don’t have machines to test MySQL monitoring for the following OSes. Perhaps you would like to be a test candidate for the new version of Monolith? If so, let me know and you’ll be on the list, as well as get beta testing credit.
OSX Server: PPC and Intel
AIX
FreeBSD / OpenBSD / NetBSD
Windows Server
Solaris: Intel & Sparc
Linux servers that are NOT Intel based.
What this involves: testing the client script, perl modules, snmp stats, and other functions that may require a custom client script for that architecture.
 |
 |
 |
 |
 |
 |