Le blog de la CT2C

Process Monitoring Ruby - God

Par Régis Millet aka Kulgar , publié le 7 Octobre 2013

God est ce qu’on appelle un “process monitoring”, ou, en français, un processus dédié à la surveillance d’autres processus. Le principe est très simple : à intervalle régulier ou selon certains événements, God va analyser si les processus qu’il est chargé de surveiller sont toujours en cours d’exécution. Ca peut être en vérifiant la présence d’un fichier “pid” par exemple. Si le processus ne tourne plus, God va essayer de le relancer à plusieurs reprises jusqu’à ce que le processus soit de nouveau opérationnel.



Mais god ce n’est pas que ça. C’est avant tout un framework développé en Ruby, donc très facile à prendre en main pour les initiés à ruby (et pour les non initiés, sachez que ce n’est tout de même pas sorcier, pas plus qu’un autre process monitoring). Grâce à ses méthodes préfaites, God permet de surveiller ses différents processus de façon simple et est vraiment conçu pour ne demander que peu d’efforts d’installation et de configuration.

Dans ce petit tuto, nous allons découvrir les bases de God et comment l’installer et l’utiliser pour surveiller un processus tel que les très fameux “DelayedJobs” de la gem du même nom de Ruby On Rails.

Requis pour suivre ce tuto :
- Environnement ruby installé (1.9+)
- Une application Ruby On Rails utilisant Delayed Job
- Des connaissances au moins basique de Ruby
- Quelques connaissances d'admin système, notamment savoir ce qu'est un daemon

Découvrons god


1. Installation et premier processus surveillé
Installons tout d’abord god : (utilisez sudo pour une installation de god partagée sur le système, il faudra ensuite toujours l’exécuter avec sudo)
$ (sudo) gem install god

Bien ! Comme dans la documentation de god, amusons-nous à mettre en place notre tout premier processus sous la surveillance de god.

Créez un fichier “simple.rb” :
# simple.rb
loop do
puts ‘Hello’
sleep 1
end

Ce simple fichier va afficher Hello toutes les secondes. Créons maintenant notre fichier god “simple.god”, dans le même répertoire :
# simple.god
God.watch do |w|
w.name = "simple"
w.start = "ruby /chemin/vers/simple.rb"
w.keepalive
end

Ce bloc de code est vraiment le plus simple possible. God.watch est LA commande la plus utile, elle représente un processus que nous souhaitons garder sous la surveillance de god. Tout processus surveillé doit posséder au minimum :
- un nom UNIQUE (w.name) (ne jamais donner 2 mêmes noms à 2 processus différents)
- la commande indiquant à god comment lancer le processus (w.start)

w.keepalive est également très important. C’est cette instruction qui indique à God qu’il doit relancer le processus, si jamais ce dernier venait à s’arrêter.

God va également se charger automatiquement de lancer le processus en tant que “daemon” (processus tournant en arrière-plan). Il va s’occuper tout seul du fichier “pid” et le supprimer/créer lors de l’arrêt ou de la relance du processus. Nous verrons, avec les DelayedJob, comment spécifier à God un fichier “pid” déjà créé, étant donné que les delayed jobs se lancent automatiquement en arrière-plan et créent leur propre fichier pid.

Lançons God :
$ god -c chemin/vers/simple.god -D

L’option -c permet de spécifier le chemin vers le fichier de configuration de god. Attention ! Un seul fichier de configuration peut être chargé par processus god lancé. Je vous expliquerai, en troisième partie du tutoriel, comment maintenir plusieurs fichiers de configuration dans différentes applications et les faire charger tous ensemble par god.

L’option -D lance god dans votre terminal (il n’est donc pas lancé en tant que daemon) et vous pourrez y voir directement les journaux générés par god.

→ God m’affiche une erreur :
ERROR: No pid file directory exists, could be created, or is writable at any of /var/run/god, ~/.god/pids

Si vous avez installé god en tant que root, créez le dossier /var/run/god :
$ sudo mkdir /var/run/god

Sinon, créez le dossier ~/.god/pids

C’est dans ce dossier que god stockera les fichiers pid des processus qu’il exécute en tant que daemon pour nous (i.e. God s'occupe pour nous de mettre les processus en arrière-plan si ces derniers ne sont pas déjà en arrière-plan). Une fois fait, relancez la commande pour exécuter God. Vous devriez voir quelque chose comme ça :
I [2013-10-04 15:03:12]  INFO: Loading ./simple.god
I [2013-10-04 15:03:12] INFO: Syslog enabled.
I [2013-10-04 15:03:12] INFO: Using pid file directory: ~/.god/pids
I [2013-10-04 15:03:12] INFO: Started on drbunix:///tmp/god.17165.sock
I [2013-10-04 15:03:12] INFO: simple move 'unmonitored' to 'up'
I [2013-10-04 15:03:12] INFO: simple moved 'unmonitored' to 'up'
I [2013-10-04 15:03:12] INFO: simple [trigger] process is not running (ProcessRunning)
I [2013-10-04 15:03:12] INFO: simple move 'up' to 'start'
I [2013-10-04 15:03:12] INFO: simple start: ruby /chemin/vers/simple.rb
I [2013-10-04 15:03:12] INFO: simple moved 'up' to 'up'

Maintenant, arrêtons le processus, trouvez-le à l’aide de la commande :
$ ps -Fe | grep simple.rb

Et tuez-le :
$ sudo kill process_pid

Vous verrez de nouveaux journaux dans God :
I [2013-10-04 15:07:06]  INFO: simple [trigger] process is not running (ProcessRunning)
I [2013-10-04 15:07:06] INFO: simple move 'up' to 'start'
I [2013-10-04 15:07:06] INFO: simple start: ruby /chemin/vers/simple.rb
I [2013-10-04 15:07:06] INFO: simple moved 'up' to 'up'

Indiquant qu’il a bien remarqué que le processus s’était arrêté et qu’il l’a relancé. Magique !

Note : J’ai dit en introduction que God surveillait à intervalles réguliers que le processus était toujours en cours d’exécution. Cela dépend en fait des systèmes d’exploitation. Certains systèmes envoient des événements lorsqu’un processus est arrêté ou lancé. Si votre système d’exploitation possède cette utilisation d’événements, God va automatiquement les intercepter et agir en conséquence. Ce sont les journaux que vous voyez ci-dessus. Lorsque j’ai tué le processus, God a intercepté l’événement envoyé par le système indiquant que tel processus s'arrêtait et a tenté de le relancer.

Sur d’autres systèmes, vous observerez dans les journaux que God effectue une vérification à intervalles réguliers. Ne vous inquiétez pas, God est conçu pour basculer automatiquement sur l’un ou l’autre comportement selon ce qu’offre votre système. Par défaut, il préfère utiliser le système d’événements.


2. Nouvelles conditions
God n’est pas qu’un simple processus permettant de relancer d’autres processus s’ils meurent. Il peut aussi analyser pour vous les ressources utilisées par vos processus et les relancer s’ils en consomment de trop. Vous restez entièrement maître de vos conditions et pouvez préciser n’importe quel seuil. Modifions notre exemple précédent comme ceci (je récupère ces exemples de la doc de God, ils devraient donc fonctionner) :

# simple.god
God.watch do |w|
w.name = "simple"
w.start = "ruby /full/path/to/simple.rb"
w.keepalive(:memory_max => 150.megabytes,
:cpu_max => 50.percent)
end

# simple.rb
data = ''
loop do
puts 'Hello'
100000.times { data << 'x' }
end

Remarquez comme nous avons ajouté 2 conditions dans la fonction “keepalive” concernant la RAM maximum utilisable en Megabytes (God est développé en Ruby, donc les méthodes de Ruby sont disponibles dans les fichiers .god, comme .megabytes ou .gigabytes) et la CPU en %.

Comment faire pour que God prenne en compte nos modifications ? Si vous arrêtez le processus God (ctrl +C dans le terminal exécutant God), le serveur simple.rb ne sera pas arrêté. Ce n’est pas parce que vous arrêtez un “process monitoring” qu’il va s’amuser à tuer tous les process monitorés (à moins que vous ne lui disiez explicitement de le faire).

Il est en fait beaucoup plus simple de relancer un processus surveillé par God. Dans un autre terminal, exécutez cette commande :

$ god restart simple
Sending 'restart' command

The following watches were affected:
simple

Où “simple” est le nom que nous avions donné à notre processus God tout à l’heure, la variable : w.name. Remarquez ce qui est renvoyé par God : il nous confirme que le processus surveillé qui a été relancé.

Comme nous avons ajouté des conditions sur la RAM et la CPU, God va maintenant nous fournir en prime des rapports sur les ressources utilisées par le processus surveillé. Vous devriez avoir des journaux ressemblant à ceux-ci :

I [2011-12-07 14:54:37]  INFO: simple [ok] process is running (ProcessRunning)
I [2011-12-07 14:54:37] INFO: simple [ok] memory within bounds [2032kb] (MemoryUsage)
I [2011-12-07 14:54:37] INFO: simple [ok] cpu within bounds [0.0%%] (CpuUsage)
I [2011-12-07 14:54:42] INFO: simple [ok] process is running (ProcessRunning)
I [2011-12-07 14:54:42] INFO: simple [ok] memory within bounds [2032kb, 13492kb] (MemoryUsage)
I [2011-12-07 14:54:42] INFO: simple [ok] cpu within bounds [0.0%%, *99.7%%] (CpuUsage)
I [2011-12-07 14:54:47] INFO: simple [ok] process is running (ProcessRunning)
I [2011-12-07 14:54:47] INFO: simple [ok] memory within bounds [2032kb, 13492kb, 25568kb] (MemoryUsage)
I [2011-12-07 14:54:47] INFO: simple [ok] cpu within bounds [0.0%%, *99.7%%, *100.0%%] (CpuUsage)
I [2011-12-07 14:54:52] INFO: simple [ok] process is running (ProcessRunning)
I [2011-12-07 14:54:52] INFO: simple [ok] memory within bounds [2032kb, 13492kb, 25568kb, 37556kb] (MemoryUsage)
I [2011-12-07 14:54:52] INFO: simple [trigger] cpu out of bounds [0.0%%, *99.7%%, *100.0%%, *98.4%%] (CpuUsage)
I [2011-12-07 14:54:52] INFO: simple move 'up' to 'restart'

God va analyser les ressources utilisées par l’application. Si sur trois cycles (1 cycle dure 5 secondes, par défaut), les ressources utilisées sont supérieures au seuil spécifié, God va relancer le processus. C’est ce qui se passe au niveau des deux dernières lignes. “CPU out of bounds” indique que le processus a dépassé le seuil sur 3 cycles consécutifs.

Note : faites bien attention aux pics éventuels de ressources utilisées par vos processus surveillés lorsque vous spécifiez des conditions sur la RAM et le CPU. Autrement, votre processus pourrait être relancé dans des périodes de fonctionnement à forte charge et vous ne voudriez sûrement pas que cela arrive en plein pic de fréquentation de votre site.

Il y aurait beaucoup à dire sur God et les conditions. Pour ne pas trop vous ennuyer, nous allons directement passer au cas pratique avec les DelayedJobs et nous verrons ensuite toutes les nouveautés dans le code de god.

God et Delayed Jobs


1. Le fichier de configuration “application_tasks.god”
Créez à la racine de votre projet Rails le fichier “application_tasks.god” (renommez application comme vous le souhaitez, avec le nom de votre projet, par exemple). Et copiez/collez le code suivant :

ENV = “production”
if ENV == "production"
PROJECTS_ROOT = “/var/www/”
application_root = "#{PROJECTS_ROOT}/application.fr"
application_shared_root = application_root
else
PROJECTS_ROOT = “/home/user/RailsWorkspace”
application_root = "#{PROJECTS_ROOT}/ActualProjectsWorkspace/application"
application_shared_root = application_root
end

God.watch do |w|
w.name = "application-delayed-job"
w.group = "application"
w.interval = 1.minute

w.start = "/bin/bash -c 'cd #{application_root}; /usr/bin/env RAILS_ENV=#{ENV} script/delayed_job start > /tmp/application_delay_job.out'"
w.stop = "/bin/bash -c 'cd #{application_root}; /usr/bin/env RAILS_ENV=#{ENV} script/delayed_job stop'"

w.log = "#{application_shared_root}/log/god_delayed_job.log"
w.start_grace = 30.seconds
w.restart_grace = 30.seconds

w.pid_file = File.join(application_shared_root, "tmp/pids/delayed_job.pid")

w.behavior(:clean_pid_file)

w.start_if do |start|
start.condition(:process_running) do |c|
c.interval = 15.seconds
c.running = false
end
end

w.restart_if do |restart|
restart.condition(:memory_usage) do |c|
c.above = 150.megabytes
c.times = [3,5]
end
restart.condition(:cpu_usage) do |c|
c.above = 30.percent
c.times = 8
end
end

w.lifecycle do |on|
on.condition(:flapping) do |c|
c.to_state = [:start, :restart]
c.times = 5
c.within = 10.minute
c.transition = :unmonitored
c.retry_in = 10.minutes
c.retry_times = 5
c.retry_within = 2.hours
end
end
end

2. God - c’est du ruby
Décortiquons tout ça morceaux par morceaux. Le premier bloc, c’est du code ruby :

ENV = “production”
if ENV == "production"
PROJECTS_ROOT = “/var/www/”
application_root = "#{PROJECTS_ROOT}/application.fr"
application_shared_root = application_root
else
PROJECTS_ROOT = “/home/user/RailsWorkspace”
application_root = "#{PROJECTS_ROOT}/ActualProjectsWorkspace/application"
application_shared_root = application_root
end

Nous y définissons deux constantes : ENV et PROJECTS_ROOT. J’ai utilisé la petite astuce de la constante “ENV” pour facilement réutiliser ce script selon si je suis en local, en mode “développement” ou en production.
En fonction de la valeur de cette constante, je définis :
- la constante “PROJECTS_ROOT” représentant le dossier racine contenant toutes mes applications Rails et évidemment différent selon si je suis en local ou non,
- la variable “application_root” qui sera réutilisée par la suite et qui contient le chemin absolu vers la racine de mon projet,
- la variable “application_shared_root”, contenant le chemin vers les fichiers partagés de l’application… C’est avant tout pour un déploiement “capistrano” que j’ai fait cette distinction. En effet, avec Capistrano, vous possédez un dossier “shared” stockant des fichiers partagés entre toutes les versions de votre application, y compris les fichiers journaux générés par cette dernière. Et nous avons justement besoin d’accéder au dossier des fichiers partagés dans notre utilisation de God. Évidemment, si vous ne déployez pas avec Capistrano, la variable application_shared_root est égale à application_root.

Note : si vous vous posez des questions quant à l’utilité de PROJECTS_ROOT, attendez la troisième partie de ce tutoriel.

3. Les paramètres primordiaux
God.watch do |w|
w.name = "application-delayed-job"
w.group = "application"
w.interval = 1.minute

Nous retrouvons notre God.watch déjà vu auparavant et le paramètre w.name. Je rappelle que ce nom doit être unique, remplacez-le donc par le nom de votre application. Notez qu’un même fichier .god peut contenir plusieurs blocs de code God.watch et donc que pour une même application Ruby On Rails, vous pouvez souhaiter surveiller différents processus (le serveur Passenger, Mongrel, ClockWork, DelayedJob, Redis…). Pour faciliter la gestion de l’ensemble de ces processus, nous pouvons assigner un groupe à l’aide de : w.group

Grâce à ça, nous pouvons exécuter la commande :
$ god restart group_name (ici “application”)
Pour relancer tous les processus appartenant à un même groupe.

Enfin, w.interval force God dans une configuration de surveillance par intervalle régulier. Ici, je lui demande de regarder toutes les minutes si les DelayedJob tournent. Évidemment, pour un serveur Rails, je ne mettrais sûrement pas cet intervalle, ou un intervalle beaucoup plus court. Mais pour des DelayedJob, c’est amplement suffisant.

  w.start = "/bin/bash -c 'cd #{application_root}; /usr/bin/env RAILS_ENV=#{ENV} script/delayed_job start > /tmp/application_delay_job.out'"
w.stop = "/bin/bash -c 'cd #{application_root}; /usr/bin/env RAILS_ENV=#{ENV} script/delayed_job stop'"

w.log = "#{application_shared_root}/log/god_delayed_job.log"

Nous connaissons aussi w.start. Je réutilise ici les variables définies précédemment (application_root, la constante ENV) pour exécuter la commande permettant de relancer les delayed jobs. Notez qu’il s’agit ici d’un simple petit script bash faisant un “cd” vers le dossier racine de l’application et exécutant la commande usuelle pour lancer les delayed jobs.

Je spéficie aussi un fichier dans lequel insérer ce que retourne la commande lançant les delayedjobs. Ca nous permettra de facilement voir toute erreur d’exécution.

w.stop est très explicite : elle permet de stopper les delayed jobs. Cette commande sera utilisée si vous exécutez :
$ god stop application-delayed-job

w.log indique le fichier journal stockant les informations renvoyées par god concernant ce processus. (Ce fichier journal affichera surtout lorsque le processus sera arrêté/relancé). Je réutilise ici la variable application_shared_root pour placer les journaux dans le dossier partagé de Capistrano si besoin. Ils seront ainsi bien plus simples à retrouver car placés avec les autres journaux de l’application Rails.

  w.start_grace = 30.seconds
w.restart_grace = 30.seconds

w.pid_file = File.join(application_shared_root, "tmp/pids/delayed_job.pid")

w.behavior(:clean_pid_file)

“start_grace, restart_grace, stop_grace” sont optionnels. Ils indiquent simplement à God le laps de temps à attendre après l’exécution de la commande avant de reprendre le service de surveillance. I.E. ici, God attendra 30 secondes avant de se remettre à surveiller les DelayedJobs si jamais on les relance. La première vérification s’effectuera donc après 1m30 secondes.

Note : Pourquoi cette attente de 30 secondes ?
Ces 30 secondes sont nécessaires. En effet, l’environnement Ruby On Rails est chargé entièrement lorsqu’on lance les DelayedJobs. Il faut donc attendre le temps que cet environnement soit chargé avant que God ne fasse son travail, sans quoi il pourrait considérer que les DelayedJob sont éteints alors qu’ils sont juste en train de charger l’environnement Rails de l’application.


Ah ! Le fameux “pid_file”. C’est ici que nous indiquons le chemin vers le fichier pid créé par les delayed jobs. Ce fichier se trouve généralement dans le dossier tmp/pids du projet Rails. Et sur Capistrano, ce dossier se trouve dans le dossier “shared”, d’où l’utilisation de File.join avec la variable “application_shared_root”.

Enfin, “behavior” spécifie des commandes supplémentaires à exécuter avant ou après l’exécution des commandes stop/start/restart. God possède quelques commandes pré-conçues, dont “clean_pid_file”. Cette commande va tout simplement supprimer le fichier pid du processus si jamais on le relance à l’aide de god. Pourquoi ? Car si nous relançons les DelayedJob alors qu’un fichier “pid” est toujours présent, ils nous renverront une erreur “There is already a pid file…”. Il est donc nécessaire de supprimer ce fichier pid pour que les DelayedJobs se relancent dans de bonnes conditions.

4. Les conditions
  w.start_if do |start|
start.condition(:process_running) do |c|
c.interval = 15.seconds
c.running = false # Teste si le processus n'est plus en cours d'exécution - notez qu'il ne faut pas utiliser ==
end
end

Un bloc de code “Watch” peut prendre en compte des conditions comme celle ci-dessus en fonction des actions à exécuter. Nous ajoutons ici une condition pour l’action “start” du processus. La méthode .condition prend en paramètre un type de condition. Ici, il s’agit de surveiller que le processus tourne. La condition correspondante est “process_running”. Si cette condition renvoie “vraie”, l’action correspondante sera exécutée.

Notez la présence de c.interval = 15.seconds. Spécifier cet intervalle à ce niveau permet d'écraser l'intervalle par défaut (rappelez-vous nous avions mis 1.minute). Ici, God va vérifier toutes les 15 secondes si le processus est en cours d’exécution ou non. Cette possibilité de définir un intervalle différent de celui par défaut nous permet d’exécuter des tests plus critiques de façon plus fréquente que d’autres tests moins critiques. Évidemment, le test “le processus est-il en cours d’exécution ?” est bien plus critique que le test “le processus dépasse-t-il les limites des ressources ?”

  w.restart_if do |restart|
restart.condition(:memory_usage) do |c|
c.above = 150.megabytes
c.times = [3,5] end

restart.condition(:cpu_usage) do |c|
c.above = 30.percent
c.times = 8
end
end

Même principe que pour start_if,sauf que nous spécifions deux conditions. Comme nous ne l’écrasons pas par c.interval, ces 2 conditions seront vérifiées toutes les minutes. c.times permet d’indiquer combien de fois cette condition doit être vérifiée avant d’exécuter l’action associée. Par exemple, si l’application utilise plus de 150 mégas de RAM pendant 3 intervalles sur un total de 5 intervalles consécutifs, l’action restart sera exécutée. Exemple, le processus a les journaux suivants : [250mb, 100mb, 160mb, 130mb, 110mb]

Si au cycle suivant l’application dépasse encore 150mb, elle ne sera pas relancée car elle aura :
[100mb, 160mb, 130mb, 110mb, 180mb] donc seulement 2 cycles > à 150 mb sur 5 cycles. Si en revanche elle dépasse de nouveau : [160mb, 130mb, 110mb, 180mb, 200mb], elle sera relancée car ici 3 cycles sur 5 dépassent 150mb.

Pour le processeur, c’est plus simple : si le processus dépasse une utilisation de 30% sur 8 vérifications consécutives, il sera relancé.

  w.lifecycle do |on|
on.condition(:flapping) do |c|
c.to_state = [:start, :restart] c.times = 5
c.within = 10.minute
c.transition = :unmonitored
c.retry_in = 10.minutes
c.retry_times = 5
c.retry_within = 2.hours
end
end

Lifecycle est un peu spécial. Les conditions précisées à l’intérieur de ce bloc seront appliquées quelque soit l’état du processus (stopped/running,restarting etc.). La condition “flapping” est également spéciale. Elle permet de modifier le comportement de God vis-à-vis de l’exécution du processus. Si nous traduisons la condition, cela donne :

Si le processus est lancé ou relancé (c.to_state) 5 fois (c.times) en moins de 10 minutes (c.within) alors arrête la surveillance du processus (c.transition) car cela signifie que quelque chose ne va pas. 10 minutes plus tard (c.retry_in) essaie de relancer le processus, car le problème n’était peut-être que temporaire (ça peut être par exemple un autre processus qui est temporairement mort ou inaccessible).
Si tout ceci survient 5 fois (c.retry_times) en moins de 2 heures (c.retry_within), alors God arrêtera totalement la surveillance, car cela signifie que le problème semble bien plus permanent et qu’il faudrait l’intervention d’un développeur / admin.

Note : Vous trouverez sur la documentation de God en ligne une liste des conditions utilisables comme "process_running", "flapping", etc.

Et voilà, nous avons tout épluché ! Je vais maintenant vous présenter comment surveiller de multiples processus présents dans différentes applications tout en gardant le tout très propre.

Multi Rails App et God


Cette partie va être beaucoup plus courte que les autres.
Souvenez-vous, nous avons placé notre document de configuration god à la racine de notre projet Rails. Et c’est très bien ainsi, il sera pris dans la boucle “git” et pourra être facilement maintenu/mis à jour en fonction des éventuelles modifications de l’application.

Seulement voilà… Sur un serveur, vous pouvez avoir plusieurs applications Rails avec plusieurs processus à surveiller par God. Mais God ne prend en compte qu’un seul fichier de configuration “.god” lorsqu’on l’exécute. Alors, comment faire ?

Simple ! A la racine du dossier contenant toutes vos applications rails (par exemple “/var/www”), créez le fichier : almighty.god

# almighty.god
ENV = "production"

if ENV == "production"
PROJECTS_ROOT = "/var/www/"
else
PROJECTS_ROOT = "/home/user/RailsWorkspace"
end

load File.join(File.dirname(__FILE__), 'application1.fr', 'application1_tasks.god')
load File.join(File.dirname(__FILE__), 'application2.fr', 'application2_tasks.god')
load File.join(File.dirname(__FILE__), 'application3.com', 'application1_tasks.god')

Remarquez comme j’ai déplacé nos deux constantes ENV et PROJECTS_ROOT dans ce fichier (n’oubliez pas de supprimer ces constantes du fichier concernant les delayed_job). L’astuce réside évidemment dans l’instruction “load” qui charge chaque fichier de configuration god placé dans nos différents projets Rails.
Si nous exécutons :
$ god -c chemin/almighty.god

God chargera également les 3 autres fichiers .god et chacun de ces 3 fichiers aura accès à toutes les variables et constantes définies dans almighty.god.

Si c’est pas beau ça ?

Linux et God


Reste à lancer God au boot de votre serveur Linux - pour les utilisateurs Linux. Pas de mystères, nous allons ajouter un script à /etc/init.d appelé god :

#!/bin/sh
# god init script
### BEGIN INIT INFO
# Provides: god
# Required-Start: $all
# Required-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: God
### END INIT INFO

# En local pour dev
#PATH=/home/user/.rvm/bin:/sbin:/bin:/usr/sbin:/usr/bin
#CONFIGFILE=/home/user/RailsWorkspace/all.god
#DAEMON=/home/user/.rvm/bin/boot_god

source /usr/local/rvm/environments/ruby-1.9.3-p385

#PATH=/usr/local/rvm/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC="God Monitoring Tool"
NAME=god
DAEMON=/usr/local/rvm/bin/boot_god
PIDFILE=/var/run/god.pid
LOGFILE=/var/log/god.log
SCRIPTNAME=/etc/init.d/god
CONFIGFILE=/var/www/almighty.god

#DEBUG_OPTIONS="--log-level [debug|info|warn|error|fatal]DEBUG_OPTIONS="--log-level debug"

# Exit if 'god' gem is not available
[ -x "$DAEMON" ] || (echo "God gem isn't available"; exit 0)

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

RETVAL=0

case "$1" in
start)
echo -n "Starting $DESC: "
$DAEMON -l $LOGFILE -P $PIDFILE $DEBUG_OPTIONS -c $CONFIGFILE
RETVAL=$?
echo "$NAME."
;;
stop)
echo -n "Stopping $DESC: "
$DAEMON terminate
RETVAL=$?
echo "$NAME."
;;
restart)
echo -n "Restarting $DESC: "
$DAEMON terminate
$DAEMON -l $LOGFILE -P $PIDFILE $DEBUG_OPTIONS -c $CONFIGFILE
RETVAL=$?
echo "$NAME."
;;
status)
$DAEMON status
RETVAL=$?
;;
*)
echo "Usage: god {start|stop|restart|status}"
exit 1
;;
esac

exit $RETVAL

Un script assez simple en fait. Celui-ci étant rédigé pour fonctionner de pair avec RVM, n’oubliez pas de remplacer les différentes constantes au début du fichier avec les valeurs adéquates pour votre environnement (y compris la version ruby). Avec ça, il ne vous reste plus qu’à exécuter :

$ which god
> path/to/god
$ ln -s path/to/god /usr/local/rvm/bin/boot_god
$ sudo chmod a+x god
$ sudo update-rc.d god defaults
$ sudo /etc/init.d/god start
# Et optionnellement :
$ sudo ln -s /usr/local/rvm/bin/boot_god /usr/local/bin/god
# Pour ensuite pouvoir faire :
$ sudo god restart my-process-name

Et vous êtes parés !

---

Ceci termine ce tuto, je vous conseille de jeter un oeil à la documentation God et aux ruby docs.
Il y a aussi un Google Group si vous avez besoin d’assistance. Une fois que vous comprendrez mieux comment fonctionne God, et après que vous en ayez assez de voir vos processus s’arrêter sans jamais se relancer d’eux-mêmes, je peux vous dire que vous ne pourrez plus vous passer de cet outil !

Il existe évidemment d'autres process monitoring, mais God est vraiment conçu pour rester léger, et surtout, il a été développé pour les développeurs Ruby, pour avoir un process monitoring simple à mettre en place.


Index -- --

Ct2c slider fleche top
  • Aucun commentaire - Soyez le premier !

Insérez votre commentaire
  1. Min: 50 caractères, Max: 800. Actuellement: 0 caractères

  2. ne pas remplir