curl install.amon.cx | bash
I'm looking at you, rvm, npm et al. Yeah, I'd just love you to poop files randomly into my filesystem, with no tracking, and a completely non-standard uninstall process (if I'm lucky enough to have one at all).
We evolved package management for a reason - I know it's a pain to have to make a .deb, a .rpm and a .tar.gz - but is it really that much more work than making an entirely custom install script?
I could probably deal with the installation, although I hate installing all those daemons and init scripts myself, but installing Mongo just for one thing, gah. Too bad there isn't an embedded version of Mongo, and my own goatfish is still far from mature.
Also, it seems that your demo (http://live.amon.cx:2464/) is down, which is a pity as I'd obviously like to try it before installing.
EDIT: And local monitoring is a big plus, too.
* Alerts via SMS (possibly by integrating Twilio / Tropo).
* API via zeromq instead of HTTP. Async logging via workers. This could become handy if you log lots of things. It would also prevent logging to become the bottleneck of my applications.
Yes, I realize that those and this probably don't perfectly overlap.
EDIT: My point isn't that Amon is "better" than Monit, only that it's different. There is some overlap in feature set, but ultimately, the tools have different goals.
Is that something that comes with the Plus version ?
The most obvious difference is that Amon runs on your hardware, so the data stays with you. The pricing model is fundamentally different than services like Server Density, New Relic, Scout, etc in that you pay per major version, rather than per-month.
Amon is currently pre-1.0, so it's hard to compare with a mature service like Server Density. They're (Amon) no where near feature parity with SD. Then again, SD will quickly cost you many times the licensing cost of Amon when you're monitoring multiple servers.
For me, the value judgement will have to wait. With services like Server Density you are (theoretically) offloading a lot of maintenance overhead to the SaaS provider. If Amon delivers on their "one line installer" promise, then it will at least have "effort parity" with many SaaS providers.
I have to wait because they're pre-1.0, so while their software is inexpensive and easy to use, there is a distinct lack of critical features. If I'm making the evaluation (whether to roll this in to production) today, I can't live without alerts, so Amon is out. Based on the way things are looking, I'd say that Amon has a bright future though. I might buy an early release, just to get up to speed on it.
Tangent: Where did you see that Amon is open source? I see that I can get access to the source by licensing it, but I don't see any mention of open source on the pages I viewed.
Amon Plus can monitor more than one machine.
Also, on the open source thing, it's closer to open-core. The single-server version is open, but, if you want to monitor more than one box, you'll need the Plus version, which, despite being distributed with source, is not, AFAIK, open.
The MongoDB installation that Amon sets up is not in a replica set nor sharded, so it leaves you to deal with redundancy, failover and scaling. We use MongoDB for Server Density and I can tell you that managing huge quantities of data is not easy.
Users are instructed to check their python version with `python -v`, but the correct command is `python -V` (uppercase).
Found a few issues so far and the response time on support has been pretty quick, I hope development keeps up :)