This isn’t the prettiest code but it means that we can keep everything contained in one file. If mem > 200.0 MB for 1 cycles then restart Stop program = "/usr/bin/test -s & & /bin/kill -QUIT `cat `" We can handle this scenario with Capistrano roles so that each task is called in a separate task.Ĭheck process _unicorn_worker_ with pidfile We could just add this to the setup task with another call to monit_config but the database might be running on a different server from Nginx. Now that we have a config file for Postgres we need to copy it to the server when we run the monit:setup task. (We could move the port number into the recipe file, too, to make it easier to change the port number.) If Postgres doesn’t respond on that port we restart its process and again we stop monitoring if we have to restart it five times in five cycles. We also check to see that the database is responding on port 5432.
This makes this more flexible if we change the version we’re running. We’re using erb to pass in the path to the pid file (this is defined in the Postgres recipe file and includes the version number). If 5 restarts within 5 cycles then timeout If failed host localhost port 5432 protocol pgsql then restart Stop program = "/etc/init.d/postgresql stop" Start program = "/etc/init.d/postgresql start" To get this working we have to include it in our deploy.rb file so we’ll add it to the list of recipes that we load in. If you’re unfamiliar with defining Capistrano tasks like this there’s more information about this in episode 337. Both of these tasks delegate to the service monit command with that given task passed in. The setup task will then run two other tasks: syntax to check the syntax of the configuration file then reload to reload the config files. We pass this the configuration file’s name which determines the template file that will be run, move this file into the conf.d directory then set the ownership and permissions. This calls a monit_config method which is defined at the bottom of the file.
#Monit program install#
Here we define several tasks, one to install Monit in case we’re installing this on a new server and another to set up Monit by copying over the configuration files.
#Monit program how to#
We also need to tell Monit how to start and stop the program. We could make this path dynamic with some erb if we wanted to configure it through Capistrano, but we won’t do that here. We do this by calling check process, giving it a name and passing in a pidfile option with the path to Nginx’s pid. Our goal here is to monitor Nginx and restart it if it fails. Note that this is an erb file so that we can add dynamic content. Our first file will be for configuring Nginx. As there are multiple configuration files for Monit we’ll make a new monit directory under /config/recipes/templates. This way we can create templates for the configuration files which can be generated and copied to any server using Capistrano. It’s a good idea to create Capistrano recipes for setting up the server, like we did in episode 337. We could set up this configuration directly on the server by adding files to the /etc/monit/conf.d directory but it’s generally better not to do extensive configuration on the server but instead to put configuration files within our Rails application under source control. Monit will then check this process and we can tell it what to do if the process fails. This tells us that we can run the check process command to do this, passing in a unique name and a pidfile.
#Monit program manual#
The manual is a good resource when editing the configuration and there’s a Configuration Examples page that is useful. That’s all we need to do to this configuration file and next we’ll instruct Monit to monitor our Rails application. We don’t have any files in this directory but if we want to configure Monit for various processes such as Nginx or Unicorn this is a good place to put them. The last line tells Monit to include any configuration files that appear in the conf.d directory. The next few lines configure various file paths and then we have an eventqueue setting that tells Monit to remember any alert messages that it can’t send over email. We’ll change this to 30 seconds so that the application is checked more frequently. The first line above tells Monit to run in the background and to perform a check every two minutes. Slots 100 # optionally limit the queue size Set daemon 120 # check services at 2-minute intervalsīasedir /var/lib/monit/events # set the base directory where events will be stored
0 kommentar(er)
