This is the second or third time I've seen a service like this created (getexceptional.com and airbrake.io are two that come to mind quickly).
I can only hope this trend continues and in an open-architecture style. The ability to basically develop a skeleton monitoring UI that I can plug my own software into is fantastic.
My only thought is: why is this local to the machine I put it on? I'd rather have a central repository that I send me data to, like getexceptional. I don't mind having to set-up the process for each server I spin up, but I would prefer it if the information all aggregated to one source that I could browse through.
What I sort of imagine is registering for an Amon account and getting a unique key and identifier. Whenever I install Amon on a machine or want to call it from my code, I use that unique key and give the hardware a unique name and register my software service (pulling the hardware name from some config file automatically). Then, when I log into my central Amon account, I can browse through my exceptions and hardware details by machine name or software service.
Give me the ability to have multiple logging levels and I am in heaven.
Take it one step further: let fall-back be to either a local db or file-system and have a cron-job go through to try to fulfill the upload tasks.
That is definitely something I would pay $25-$50 a month for.
First off, some people have NDAs where they must not store any kind of file in the cloud, nor disclose anything at all (like the load of a server, graphs, the specs of the hardware, the used software, anything related to the company, its clients, its visitors or its services) to any third party.
So, as you may see, there's a point for this.
Also, don't forget that all you want for the replication already exists. You can easily replicate the mongodb data to another machine or back it up and save it somewhere else periodically.
As for giving each machine a unique id, this is a cool idea, but this implies that you have enough resources to set up your own monitoring system to monitor multiple hosts. That implies that you can implement something redundant.
First, it downloads and installs a non-checksummed i686 binary version of mongodb. This is outrageously anti-social and one should be embarrassed for releasing that. Ditto ez_setup and all that crap. This is 2011.
I'm only looking at the Debian script now, but it's littered with other bugs such as not calling update-rc.d for amon (it is called for amond). The suggestion to run "curl uninstall.amon.cx | sh" is particularly unsafe as the script has a Bash shebang and /bin/sh could be anything.
A glance at the rpm script suggests bugs fixed in one have not been copied over - for example, you use pgrep correctly in the debian script but in the rpm script you essentially do [ "$(ps aux | grep -c mongo)" = 1 ] which gives you completely the opposite result to what you want.
The uninstallation scripts are perhaps worse, riddled with typos ("/etc.init.d/amond", "torando", etc.) which demonstrate the code has never once been tested, deleting /usr/bin/mongo* even though you install it to /usr/local/ (and screw anyone who had their own version running), deleting any systemwide versions of jinja, and. It won't even uninstall on Darwin due to "[ "$(uname -s)" != "Darwin" ];". And you call "set +e" (a no-op as it's the default) so that if the site_packages shell expansion fails you try and delete "/jinja2", etc.
I'm going home now. This is just what I see on my first glance but I think I've seen enough, frankly.
First, it downloads and installs a non-checksummed i686 binary version of mongodb. This is outrageously anti-social and one should be embarrassed for releasing that. Ditto ez_setup and all that crap. This is 2011.
Amon is language agnostic, so there is enourmous chance, that a person who has 0 python knowledge could use it. By default none of the Linux distributions out there have pip or
easy_install, so I thats why I have to install it.
I'm only looking at the Debian script now, but it's littered with other bugs such as not calling update-rc.d for amon (it is called for amond)
That is for reason. Some people, especially on small VPS's prefer to keep their memory usage low, so that's why the web part is running on demand only.
It won't even uninstall on Darwin due to "[ "$(uname -s)" != "Darwin" ];"
It's not running on MacOS at all at the moment, that's still work in progress.
Just skimmed the scripts on my mobile and obviously I cannot claim to know the GP's thoughts, but one thing that stood out was a habit of using rm -rf a lot, sometimes with wildcard arguments or environment variables passed on.
I cannot judge the safety in general, but can you list a single reason for using the -f argument here? I'd bet that this is 'just in case' combined with muscle memory gone bad.
Thanks, I will remove the wildcards and rm -rf where I can. I will add more comments to the scripts, so people can instantly know what exactly is happening when they read through.
Looks very promising - I can't help wonder how you can spend time building a quality product like this, then release it for free : is there a monetization strategy at some point (i.e : pro support) ?
There is a Pro version in the works.
The idea is to have a fully working open source variant with almost everything included. But if you want to monitor multiple servers, better support for multiple apps ( for example: color filter in the web interface ), email notifications , etc - then you can buy the Pro version.
The Pro version will cost something that everyone can afford and it will be - pay once, use forever :)
Don't hesitate to charge a reasonable monthly fee. There's a lot of room to undercut the existing players (newrelic et al) and still make it a sustainable business.
Maybe I will do that, because it will be more convenient for some people. But the Pro version will always be an option for people that don't want to pay monthly charges and are OK with managing their own instances :)
P.S And of course the Open Source version will do the job for most people
I especially like the logging feature. Haven't had the chance to look at the code yet but how tightly coupled to mongodb is this? Would it be relatively easy to replace the store with redis?
Because at its best Redis is an in-memory database. That means saving log information to it ( the exceptions are log information after all ) will take RAM. And at some point you will have to migrate to bigger VPS just because of that. You can manage that with the expiring keys, but some people prefer to keep their logs for long time.
I can only hope this trend continues and in an open-architecture style. The ability to basically develop a skeleton monitoring UI that I can plug my own software into is fantastic.
My only thought is: why is this local to the machine I put it on? I'd rather have a central repository that I send me data to, like getexceptional. I don't mind having to set-up the process for each server I spin up, but I would prefer it if the information all aggregated to one source that I could browse through.
What I sort of imagine is registering for an Amon account and getting a unique key and identifier. Whenever I install Amon on a machine or want to call it from my code, I use that unique key and give the hardware a unique name and register my software service (pulling the hardware name from some config file automatically). Then, when I log into my central Amon account, I can browse through my exceptions and hardware details by machine name or software service.
Give me the ability to have multiple logging levels and I am in heaven.
Take it one step further: let fall-back be to either a local db or file-system and have a cron-job go through to try to fulfill the upload tasks.
That is definitely something I would pay $25-$50 a month for.