What Is the Advantage of Using Supervisord Over Monit

How do supervisor processes monitor processes? Can the same be done on the JVM?

Erlang OTP Supervision is typically not done between processes on different nodes. It would work, but best practice is to do it differently.

The common approach is to write the entire application so it runs on each machine, but the application is aware that it is not alone. And some part of the application has a node monitor so it is aware of node-downs (this is done with simple network ping). These node downs can be used to change load balancing rules or fall over to another master, etc.

This ping means that there is latency in detecting node-downs. It can take quite a few seconds to detect a dead peer node (or dead link to it).

If the supervisor and process runs locally, the crash and the signal to the supervisor is pretty much instantanious. It relies on a feature that an abnormal crash propagates to linked processes that crash as well unless they trap exits.

Monit : monitor remote processes

First off I am using an Ubuntu Server 16.04, So my syntax and file location may different than yours.

I was able to open the /etc/monit/monitrc and input the remote server i am trying to monitor This is the syntax I used:

Test to Check the host server remotely

check host host.domain.name with address ip.addy.here.ip
start program = "ssh user@ipaddress /etc/init.d/sshd start"
stop program = "ssh user@ipaddress /etc/init.d/sshd stop"
if failed port 22 protocol ssh
then alert

Of course you would have to use a user with priviledges.

Supervisord - using A variable INSIDE the supervisord.conf

Options

Via Inheritance from supervisord:

As long as you are using version 3.0a10 or above, you can set environment variables in [supervisord] environment and they will be in the environment of all processes under supervisord's management.

[supervisord]
...
environment=FAVORITE_VENTURE="RUSTY",FAVORITE_COLOR="RED"

Working with Variables supervisord inherited from a Shell

Supervisord also has a %(ENV_VARNAME)s expansion format for interpreting environment variables which would allow moving around variable names for different processes. But the configuration's environment section does not add to the environment variables available by the %(ENV_)s mechanism, so it would be necessary to call supervisord with variables already set by your shell.

As an example, if you use init scripts to start supervisord and are on a debian based system (i.e. Ubuntu) then you might start with the following in /etc/default/supervisor:

export SUPERVISOR_INCLUDES="main.conf test.conf"
export MAIN_RETRY_COUNT=2
export TEST_RETY_COUNT=1
MONGO_BASE="MONGO_URL=mongodb://path.to.mongo"
MAIN_MONGO_URL="${MONGO_BASE}:27017"
TEST_MONGO_URL="${MONGO_BASE}:27018"
export MAIN_ENV="${MAIN_MONGO_URL},OTHER_THING=\"Another thing with escaped quoting\""
export TEST_ENV=..

Then use them in configurations:

; supvervisord.conf
[includes]
files= %(here)s/subdir/other.conf %(ENV_SUPERVISOR_INCLUDES)s 

; main.conf
[group:main]
...
[program:mainbackend]
startretries=%(ENV_MAIN_RETRY_COUNT)s
environment=%(ENV_MAIN_ENV)s

If users can sudo and call supervisord directly, this method doesn't work very well since sudo both strips the users environment and doesn't run traditional shell init scripts. But you can source /etc/default/supervisor in root's .bashrc and use sudo bash -c "supervisord .." or source it before calling supervisord.

---

Related Topics