This will be rough!!!
Tonight after my evening (hobby) class there’s the great pre-party for the workshop
Then tomorrow there’s a lot of interesting talks, and during those
with massive hangover I should better prepare a presentation and, more importantly, the server for running my Nagios benchmarking talk on.
We’ve done a lot of optimizing our own software, Check_MK, the 1.2.0 release is (imho) awesome, and on the benchmarking side of thing we’ve squeezed it so much that it seems pointless at the moment to do any more. I don’t know any customer with performance issues…
Still, it would have been nice to have some time for prepping the talk.
The good thing is that I last used the benchmarking server for SSD/Raid benchmarks, so it’s stuffed with 8 SSDs built into one large Raid5 that gives somewhere between 500 and 740MB/s of throughput…
(If you look at the benchmark result website at http://mathias-kettner.de/checkmk_checkmk_benchmarks.html , you’ll see that thanks to our RRD Caching this is completely useless though)
Originally I had planned to fire up all 4 blades in my SuperMicro twin^2 and try to show something like 4mio checks/minute in a midrange 2U server. But that would only be fun if I finish the check for my metered PDU beforehand, and also take another 3 hours to get the server installed. 😦
Some updates that made it into Check_MK 1.2.0
- The Unix agents are now giving quite the same amount of info
- MacOS X Agent was contributed
- Checks for Veritas VxVM
- Better ZFS Checks
- Throughput / IOPS monitoring
- Database Checks for MySQL and PostgreSQL
- Tivoli TSM Monitoring
- Graphical logwatch editor
… and just the ones made over the last weeks. It’s been too much to remember any further back.
Ah, and VMWare and MSSQL Support are around the corner, too.
Also great: A user ported the full logwatch to Windows!
Also hillarious (in a very positive sense):
The docs for Jive used to recommend: Nagios, Check_MK and some others.
Now it reads: Check_MK and some others…
There’s some trend we can’t monitor yet