6 ms·
Amon - web application debugging and monitoring toolkit
- piotrSikora 15y agoWhy do people keep linking to GitHub repos instead of official websites? http://amon.cx/ http://amon.cx/
- thedjpetersen 15y agoIts nice to look at the source before you look at the actual application.
- kurt_ 15y agoIs this tool can be used with centtralized mongodb and app server to monitor more than one server ? I like its simplicity.
- dedene 15y agoThis is awesome!
- Rajiv_N 15y agoI 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?
- martin_rusev 15y agoIt was Redis once :) But Redis is not a good database for storing Rails exceptions, that's why I replaced it with Mongo.
- Rajiv_N 15y ago:) Thanks for sharing your work. If you have the time could you elaborate on why Redis is not good for Rails exceptions?
- martin_rusev 15y agoBecause 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.
- Rajiv_N 15y agoGot it! Thanks for the explanation. Makes sense.
- paisible 15y agoLooks 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) ?
- martin_rusev 15y agoThere 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 :)
- moe 15y agopay 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.
- martin_rusev 15y agoMaybe 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
- flexterra 15y agoLooks awesome. I will try to deploy this on Heroku and see how it compares to my django-sentry [https://github.com/dcramer/django-sentry https://github.com/dcramer/django-sentry] installation.
- devr 15y agoLooks great, very impressive. Is user authentication in the works? Is there an easy workaround for securing the web app?
- martin_rusev 15y agoAlmost there with the auth module, probably 2-3 days :)
- deleted 15y ago[deleted]
- choffstein 15y agoThis 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.
- deleted 15y ago[deleted]
- j_s 15y agoDoes this product match what you're looking for? (Pricing: "call for quote") http://eqatec.com/Analytics/Overview.aspx http://eqatec.com/Analytics/Overview.aspx Edit: Per the Amon website, local-to-the-machine is a feature: "You don’t trust cloud based solutions and want to be in full control of your data"
- kermitthehermit 15y agoFirst 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.
- plainOldText 15y agoOne of the cleanest monitoring tools I've encountered. Looks promising.
- lamby 15y agoThe installation and uninstallation scripts are idiotic, dangerous and clearly untested.
- martin_rusev 15y agoIf you can help with advice, I will be more than happy to listen :)
- darklajid 15y agoJust 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.
- martin_rusev 15y agoThanks, 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.
- ceejayoz 15y agoWould you care to elaborate?
- lamby 15y agoOh christ, where to even start.. 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.