God VS. Monit for Process Monitoring

God vs. Monit for process monitoring

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.

Monit to watch over God?

I would put the responsibility of keeping god running on something more core to the OS. On Ubuntu maybe you could use upstart to launch and monitor god. I haven't done this myself however.

The only other benefit of using monit for this seems to be that it might be possible to monitor god's memory usage, which in the past has had some leaks.

How to (or should I) monitor or ensure running of a monitoring software?

This reminds me of this old worm that would consist of 2 processes. If one of the processes was killed, the other one would respawn it and vice versa.

If this software is supposed to run on linux you can simply use /etc/inittab with the respawn option.

Is there benefit to using Monit instead of a basic Upstart setup?

Given that Upstart just checks the PID, a tool like Monit that makes an actual request will provide you an answer of app sanity more faithfully. A process may happily be running but stuck in some way such that it is not serving requests.

Monitor ruby processes with Monit

The Monit Wiki has a lot of configuration examples:

http://mmonit.com/wiki/Monit/ConfigurationExamples

Just pick a simple one and modify it according to your needs.

Update: the wrapper script should create the pid for you in this line:

echo $$ > /var/run/xyz.pid;

Did you adapt the script to your needs? Is it executable (chmod +x)? Does it have write permissions for the destination? Maybe post the wrapper you are trying to use so I can help you more.

How to monitor delayed_job with monit

Here is how I got this working.

1. Use the collectiveidea fork of delayed_job besides being actively maintained, this version has a nice script/delayed_job daemon you can use with monit. Railscasts has a good episode about this version of delayed_job (ASCIICasts version). This script also has some other nice features, like the ability to run multiple workers. I don't cover that here.
2. Install monit. I installed from source because Ubuntu's version is so ridiculously out of date. I followed these instructions to get the standard init.d scripts that come with the Ubuntu packages. I also needed to configure with ./configure --sysconfdir=/etc/monit so the standard Ubuntu configuration dir was picked up.

3. Write a monit script. Here's what I came up with:

   check process delayed_job with pidfile /var/www/app/shared/pids/delayed_job.pid

start program = "/var/www/app/current/script/delayed_job -e production start"

stop program = "/var/www/app/current/script/delayed_job -e production stop"
   

   I store this in my soucre control system and point monit at it with include /var/www/app/current/config/monit in the /etc/monit/monitrc file.

4. Configure monit. These instructions are laden with ads but otherwise OK.
5. Write a task for capistrano to stop and start. monit start delayed_job and monit stop delayed_job is what you want to run. I also reload monit when deploying to pick up any config file changes.

Problems I ran into:

1. daemons gem must be installed for script/delayed_job to run.
2. You must pass the Rails environment to script/delayed_job with -e production (for example). This is documented in the README file but not in the script's help output.
3. I use Ruby Enterprise Edition, so I needed to get monit to start with that copy of Ruby. Because of the way sudo handles the PATH in Ubuntu, I ended up symlinking /usr/bin/ruby and /usr/bin/gem to the REE versions.

When debugging monit, I found it helps to stop the init.d version and run it from the th command line, so you can get error messages. Otherwise it is very difficult to figure out why things are going wrong.

sudo /etc/init.d/monit stop
sudo monit start delayed_job

Hopefully this helps the next person who wants to monitor delayed_job with monit.

---

Related Topics