This is the required monit configuration ( /etc/monit/conf.d/nebulab.monitrc): Monitoring the unicorn master process is simple, we should already have everything in place by default. monitor each worker process to gracefully kill any worker which is using up too much resources.Īll the examples will refer to the nebulab application.monitor the application as a whole via the unicorn master and alert if there is any status change.We’ll see the approach we use in each of our applications:
There is a much more in-depth article (it’s great and you should read it): I like Unicorn because it’s Unix. These worker processes are actually forked from the master process, this means (in a monitoring perspective) that we can not only monitor each worker individually but also the master process as a sum of resources used up by its workers. Unicorn’s structure is simple and effective it has a “master process” which administers a number of “worker processes” that actually serve HTTP requests. Since we read so many horror stories about Ruby memory leaking all over that great unicorn fur, we chose monit as our main monitoring solution (not that its syntax is so much more complex than Ruby’s). The first two being Ruby applications while monit being a C application.
To monitor a Unicorn process you can use a multitude of tools: bluepill, god and monit. One of the most amazing things you can do with Unicorn is monitor its behavior in depth with ease and peace of mind (read UNIX Signals). It may seem initially hard (it’s so distant from that “php feeling” you get when working with Passenger) but once you unleash some Unicorn power, you can never go back. Unicorn gives you tremendous geek power and responsibility. It’s been a while since we switched all our infrastructure from Apache2 + Passenger to Nginx + Unicorn and we’ve really been satisfied with such a choice.
0 kommentar(er)
