views:

2949

answers:

5
+11  Q: 

God vs. Monit

Which one to use for process monitoring and why?

+11  A: 

Both solutions are good, and there are some pros and cons for both of them.

God config file is written in Ruby, so you can do basically everything Ruby allows you to do, and it's a lot of stuff. Monit has to be configured using its own syntax, it's usually OK but more restrictive. Anyway, you can also generate monit config with Ruby (as a part of your deployment strategy).

Also, monit uses less resources, so if you're on VPS or just don't have any spare memory, monit could be a better choice. Personally, I prefer god, as it's more configurable.

Here's a very good screencast on god. There's also a lot of feedback in comments to this screencast.

Oleg Shaldybin
Yes, god's Ruby config file (as well as built-in XMPP notifier) makes it particularly tempting for me. And since I'm on my own dedicated server I think I'm going to give it a try.
Milan Novota
Be sure to do your homework before you use god. There are some reliability problems that I've experienced as well as a few other folks I know that run major Rails applications. One thing god does very well is market itself as a magical, "easy", silver-bullet. Thats far from the truth.
Brad Gessler
+10  A: 

God leaks memory pretty badly so I chose Monit for my VPS. Monit runs at about 2MB of RAM constantly, whereas my god install running on Ruby 1.8.6 leaked out to about 60MB of RAM in about 36 hours. I didn't want to monitor my system monitoring tool so I scrapped God and went over to Monit and have had absolutely no problems.

railsninja
Does anyone know if this problem still prevails with Ruby 1.8.7? I really like the "Rubyness" of god and I'd like to give it a shot, anyway.
Milan Novota
I'm not sure, if you are keen I'd say bear it in mind and give it a shot anyway. I'm not against God, I quite liked it, I just couldn't live with the leakage. The use of it was good, just not practical for me.
railsninja
God memory leak has been fixed about year ago (testing http://blog.vortorus.net/2009/12/06/god-process-monitor-0-8-0-major-improvement)
valodzka
+4  A: 

I had a ton of problems even getting God to run at all on my dedicated Ubuntu server. I eventually just gave up. Monit may not be Ruby, but it's largely hassle-free.

Bob Aman
Can you be more specific? What kind of problems?
Milan Novota
Sure.$ sudo god checkusing event system: netlinkstarting event handlerforking off new processforked process with pid = 15795killing process[fail] never received process exit event
Bob Aman
+8  A: 

God has a lot of problems including:

  1. It leaks memory
  2. It has trouble stopping and restarting processes

I did a write-up about it at http://blog.bradgessler.com/use-monit-with-rails-not-god

The only real problem with monit (if its a problem) is that the configuration files can get a bit verbose if you're running large clusters, but this could be solved with a templating system.

Brad Gessler
We've been running monit on our clusters now for over three months and its one of the best sys-admin decisions we've made. Monit still hasn't crashed or leaked memory since we've turned it on.If you experienced the same frustrations I did with god and are peeved about it, I ask that you provide some link-bate to my blog post so when others Google "god" or "god process monitor" they can be warned with my rant.
Brad Gessler
Looks like a generous contributor has helped to (possibly) eliminate the memory leaks in god. http://groups.google.com/group/god-rb/browse_thread/thread/86bec1664757086f
Readonly
God memory leak has been fixed about year ago (testing http://blog.vortorus.net/2009/12/06/god-process-monitor-0-8-0-major-improvement)
valodzka
+1  A: 

Monit has its own issues:

  • Empty PID files cause issues.
  • If you have multiple levels of dependencies it starts up top level apps when lower level dependencies are started. This might be great for some use-cases, but its not particularly flexible.

At the moment I find it pretty annoying. Fortunately you can kinda kludge your way through the dependencies with their 'groups' feature, but its not particularly satisfying. Anyway, thats my take on v5.1.1

dsummersl