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

2

54

I'm configuring my server to run node.js as a daemon. I've setup Upstart to handle startup and shutdown of node, which works wonderfully. The next step is to make sure that node.js is restarted if it dies. A few of the guides have suggested using Monit (or Fugue) to monitor the process (in Monit's case by doing an HTTP request to the server and waiting for a response).

I'm happy to use something like Monit or Fugue, but I'm not sure why one wouldn't (or couldn't) just use Upstart's respawn feature. I assume Upstart will monitor the PID of the launched process and just kick it off again if it dies. What does Monit or Fugue give you that Upstart doesn't?

Reef answered 18/1, 2011 at 9:56 Comment(1)
you should also check out forever blog.nodejitsu.com/keep-a-nodejs-server-up-with-foreverNewmann
O
42

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.

Ozmo answered 18/1, 2011 at 10:31 Comment(3)
That's a very good point. There's more to a working webserver than simply being alive, it's actually got to be able to serve requests too!Reef
I think this pretty much settles it. Upstart respawn is fine as long as there's no chance your application could be alive but unusable. Monit is more suited to something like a webserver where it's possible for the server to be alive but unresponsive. Thanks for the answer, it's pretty plain to see now.Reef
In addition to testing local processes, I use Monit to test a few ports of remote servers and local file permissions, which is very helpful.Outflank
M
79

I highly recommend using both Monit AND upstart. Upstart makes it easy to deamonize node.js and Monit comes packed with tons of useful app checks including memory usage, http requests, cpu usage, ...

This is an example of the most basic setup you can get. You could also easily add another monit config (with the same start and stop script) but using the PID file and monitoring process stats.

For the below configuration create a simple local-only request handler in your app that just responds with status 200 if all is well.

Monit config:

check host app_name with address 127.0.0.1
    start "/sbin/start app_name"
    stop "/sbin/stop app_name"
    if failed port 80 protocol HTTP
        request /ok
        with timeout 5 seconds
        then restart

Upstart script (/etc/init/app_name):

description "app_name"

start on startup
stop on shutdown

script
    # Node needs HOME to be set
    export HOME="path/to/node/app"

    exec sudo -u nodejs /usr/local/bin/node path/to/node/app/server.js production 2>>/var/log/app_name.error.log >>/var/log/app_name.log
end script
Monochromatism answered 18/1, 2011 at 22:37 Comment(0)
O
42

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.

Ozmo answered 18/1, 2011 at 10:31 Comment(3)
That's a very good point. There's more to a working webserver than simply being alive, it's actually got to be able to serve requests too!Reef
I think this pretty much settles it. Upstart respawn is fine as long as there's no chance your application could be alive but unusable. Monit is more suited to something like a webserver where it's possible for the server to be alive but unresponsive. Thanks for the answer, it's pretty plain to see now.Reef
In addition to testing local processes, I use Monit to test a few ports of remote servers and local file permissions, which is very helpful.Outflank

© 2022 - 2024 — McMap. All rights reserved.