Godhead lets you configure God monitoring tasks to separate configuration of the program being monitored from configuration of the specific project it’s used in.
It also contains a collection of starting recipes gathered from around the web:
- Nginx
- Mongrel
- Thin
- Unicorn
- Beanstalkd
- Starling
- Memcached
- Tokyo Tyrant
- Generic worker daemons
There’s skeleton files for delayed_job, workling
Requires the gems for active_support and, of course, god. Optionally requires tlsmail (for Gmail or other secure email notification).
If you enjoy godhead you may also wish to find Jesus, the “web interface for god to speak with mankind”. Allelujah.
The examples/ directory holds:
- a script to run god as a service.
sudo cp [GODHEAD]/examples/etc/init.d/god /etc/init.d/godsudo chmod a+x /etc/init.d/godupdate-rc.d god defaults
- a god.conf that loads God, sets up notifications, and then runs all .god files in /etc/god
- an example project script to put into /etc/god
At infochimps, we have a lot of boxen set up as scrapers and as feed endpoints. These typically talk to a lightweight database of some sort, pull or push to a queue, and are controlled through a simple sinatra admin panel.
With Godhead we describe the platonic form of, say, a “god config to monitor Tokyo Tyrant”. The god files for a project using Tokyo Tyrant specifies only those few ways (port numbers, memory limits, etc) that its tasks differ from any other project’s Tokyo Tyrant tasks. Configuration is still done in Ruby, through any combination of config params and subclassing.
- God Monitoring homepage
- Railscast with God monitoring Workling and Starling
- “beanstalkd”
- delayed_job
- init.d/god script
- backgroundRb: this one – or this one