What's the point of using runit in combination with monit?

Solution 1:

I'd never heard of runit, yet I'm a heavy Monit user...

Looking at runit, I see that it's an init replacement. I'd argue that most enterprise systems stick with their default Sys V init or Upstart. I don't think it's a common practice to change it.

However, the relationship here may be that runit provides a convenient way of spawning Monit and making sure it remains running. Perhaps similar to running Monit from inittab. It's essentially "watching the watcher" or monitoring your monitoring system.

In practice, I use Monit as a daemon and have not had any issues with it crashing or being killed. Maybe the appeal of runit is that it offers some additional protection.

As for Monit, it functions well with process name pattern matching instead of PID files.

Solution 2:

runit is well suited for controlling services and logging and also well sticks to unix-way: easily combine simple parts as you need. It can do some checks and event-processing of service starts/stops but you'll have to script all this stuff yourself. Note: runit doesn't work if your service can't run in the foreground.

monit is ok for controlling services (but not so good as runit because you'll have to handle daemonizing and logging yourself) and also works good with self-daemonizing processes if they expose correct pidfile. On the other hand it is really great for watching the services: event processing, checking for memory leaks and such. Also it has nice dashboard for browsing service states (both commandline-based and web-based) and a commercial dashboard m/monit for getting data from several servers.

This way using runit+monit becomes the following:

• runit used for service supervision, logging, automatic restarts and such kind of stuff
• monit used for notifications of service state changes, more extended checks and basic service monitoring