They all suffer from inflexible data models (how many are using SQL and rrdtool in that matrix?), death at scale (what happens when you go from 10 to 500 to 3000 to 10000 servers? across three data centers? and transient xen servers?), lack of UI design, and community involvement (because of that massive comparison grid).
That's not even considering broken models for alerting (a server dies at 3am -- should it page you? no, because you have 200 of the same servers in the same roll. the load balancer will compensate.), historical logging, trending, and event aggregation/dedup.
It's a big problem, but making flexible tools from the ground up with sensible defaults can go a long way towards helping everyone.
We can fix this. We can make the redis of monitoring.
I have to laugh at you pointing out 'redis', redis can not scale at this time. Clusters are planned sometime mid-year but it'll be sometime before it has more features. Maybe you meant the MongoDB?
Alerting is quite flexible from what I read to the point that they are quite customiseable. I agree that a server dying at 3 am is not as important but should still be a valid alert to make an API call to the host to start a new server (Not sure if possible, alerts seem to be shell based).
I'd love more competition but even you point out community involvement won't be as much because there's a lot of competition. Including your offering, soon.
Disclaimer: I started researching server monitoring a few weeks ago and considering Zabbix since last week.
That's the kind of thinking Josh calls out in the article. Redis is great in most of the use cases for replicated Mongo if you're gearing the rest of your architecture to use it properly.
Within each, if you search for templates or cookbooks or config scripts, you'll find ways of configuring it easily enough.
https://secure.wikimedia.org/wikipedia/en/wiki/Comparison_of...