{"id":720,"date":"2009-04-25T08:44:05","date_gmt":"2009-04-25T13:44:05","guid":{"rendered":"http:\/\/blogs.law.harvard.edu\/hoanga\/?p=720"},"modified":"2009-04-25T07:44:21","modified_gmt":"2009-04-25T12:44:21","slug":"glad-im-not-the-only-one-who-prefers-monit-over-god","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/hoanga\/2009\/04\/25\/glad-im-not-the-only-one-who-prefers-monit-over-god\/","title":{"rendered":"Glad I&#8217;m not the only one who prefers monit over god"},"content":{"rendered":"<p>Seems someone else <a href=\"http:\/\/blog.bradgessler.com\/use-monit-with-rails-not-god\">ran into issues<\/a> while trying to deploy god.<\/p>\n<p>While, I don&#8217;t think god sucks I definitely don&#8217;t endorse it.  At this point I would only use it under the following conditions:<\/p>\n<ul>\n<li>Need for a process monitor tool with more dynamic configuration setups.  This is where god really shines against monit&#8217;s simpler understanding of what process management is about.<\/li>\n<li>The host that needs monitoring can easily spare at least 16MB for a monitoring process.  See below on why.<\/li>\n<li>I really want an all Ruby solution for all the tools in a system<\/li>\n<\/ul>\n<p>In general, I am into the whole &#8216;It is Open Source.  If you&#8217;re having issues, fix it&#8217; deal so I am not nearly as angry sounding as Brad is about god.  However, after having issues with god, I switched to <a href=\"http:\/\/mmonit.com\/monit\/\">monit<\/a> for simple process monitoring and restarting.  I had far less troubles and got on with other tasks that I considered more important than perfection in a process monitoring system.<\/p>\n<p>For those that are curious here are the issues that I ran into with god:<\/p>\n<ul>\n<li>Daemonized Ruby took at least 8MB of RAM for the monitoring process.  With RAM the way it is, this is not as big a deal.  However, if you are trying to get by on a 128MB VPS host every kilobyte counts.<\/li>\n<li>God itself had <a href=\"http:\/\/rubyforge.org\/tracker\/index.php?func=detail&amp;aid=13474&amp;group_id=3845&amp;atid=14814\">issues just randomly dying after some time<\/a>.   Tom promptly fixed it after it was reported and that was great.  However, it was a little disappointing that a monitoring process just died.<\/li>\n<li>Sparse documentation compared to monit&#8217;s.   Then again this is typical from many Ruby projects and luckily Ruby code is readable enough<\/li>\n<li>Digging up known issues for god required noodling through groups, forums, and blog posts.   Would have been nice to just have a <a href=\"http:\/\/mmonit.com\/wiki\/Monit\/FAQ\">friggin&#8217; FAQ<\/a> like <a href=\"http:\/\/cr.yp.to\/daemontools\/faq.html\">other<\/a> sys admin-targeted software I have seen.<\/li>\n<\/ul>\n<p>I also DO agree as has been said in <a href=\"http:\/\/blog.bradgessler.com\/use-monit-with-rails-not-god\">the comments on  Brad&#8217;s post<\/a> that it is the responsibility of the deployer of software to handle the issues with whatever they deploy and just deal with it.  The reason I say this is because I fell for the hyped up description of god in the beginning and ultimately paid the price when it sucked up my time.  I dealt with it but definitely am less impressed with overhyped marketing descriptions of software these days.   Personally, I am not a fan of that type of marketing for software since it seems a little disingenuous to me.   But that is just me.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Seems someone else ran into issues while trying to deploy god. While, I don&#8217;t think god sucks I definitely don&#8217;t endorse it. At this point I would only use it under the following conditions: Need for a process monitor tool with more dynamic configuration setups. This is where god really shines against monit&#8217;s simpler understanding [&hellip;]<\/p>\n","protected":false},"author":703,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1215,615,4115],"tags":[],"class_list":["post-720","post","type-post","status-publish","format-standard","hentry","category-gripe","category-ruby","category-sysadmin"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/posts\/720","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/users\/703"}],"replies":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/comments?post=720"}],"version-history":[{"count":0,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/posts\/720\/revisions"}],"wp:attachment":[{"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/media?parent=720"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/categories?post=720"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/hoanga\/wp-json\/wp\/v2\/tags?post=720"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}