Un des problèmes avec une application Ruby on Rails est que lorsque pour une raison ou une autre, votre grappe de serveur mongrel part en vrille, il faut relancer le serveurs, en effaçant éventuellement les fichiers pids qui sont resté coincés ou en tuant les processus zombie dont le fichier pid ne se situe plus dans le dossier tmp/pids
Il existe pour cela le gem « god » : http://god.rubyforge.org/ – Seulement après un test sur un de nos serveurs, cela n’a pas été concluant car pour une obscure raison, le process god tombait et du coup je n’avais plus de monitoring pour mon application Ruby on Rails.
Créer un script qui surveille god qui lui même surveille notre application me semblait un peu étrange… Du coup j’ai décidé d’écrire un petit script qui vérifiera le status de l’application et redémarrera l’application en effaçant les pids et en tuant les process mongrels.
environment = "www"
mongrel_rails = "/usr/local/bin/mongrel_rails"
result = `cd #{environment}/current && #{mongrel_rails} cluster::status`.split("\n")
result = result.map{|r| r unless r == ""}.compact
check = result.map{|r| r =~ /^found/}.compact
pids = []
ports= []
result.each do |r|
pid = r.scan /pid (\d+)$/
pids << pid.to_s.to_i if pid.size > 0
port= r.scan /port (\d+)/
ports << port.to_s.to_i if port.size > 0
end
if check.size == result.size
puts "Server OK"
else
puts "Restarting mongrel Server"
`kill -9 #{pids.join(" ")}` if pids.size > 0
ports.each do |port|
pid = `pgrep -f #{port}`
`kill -9 #{pid}` if pid != ""
end
`rm #{environment}/current/tmp/pids/*`
`cd #{environment}/current && #{mongrel_rails} cluster::restart`
file = File.new("checkapp.log", "a")
file.write("Restarting mongrel serveur\n")
file.write("==========================\n")
file.write("#{Time.now}\n")
file.write("#{result.inspect}\n")
file.write("#{ports.inspect}\n")
file.write("#{pids.inspect}\n\n")
file.close
end
Vous pouvez le voir bien formaté sur github : http://gist.github.com/86819
mars 31st, 2009 at 3:11
En effet, c’est une préoccupation essentielle en production que de s’assurer que les noeuds Mongrel sont tous en ordre de marche. Car malheureusement, il arrive fréquemment que l’un deux tombe.
Pourquoi pas écrire un script adhoc mais avez-vous regardé Monit (http://mmonit.com/monit/) ? Si vous déployez sur des noeuds Linux, ça vaut sans doute la peine que vous vous y intéressiez.
Pour notre part, nous l’utilisons sur le principal site dont nous avons la charge. Il nous permet de dormir sur nos 2 oreilles car nos utilisateurs sont principalement aux US et les problèmes arrivent souvent tard le soir ou même en pleine nuit, heure française.
Tous nos nœuds Mongrel (10), notre serveur web (NginX), notre base de données (MySQL), notre moteur de recherche (Sphinx), notre serveur de messagerie (Postfix) ainsi que quelques autres serveurs sont surveillés et relancés automatiquement par Monit selon un jeu de règles que nous avons définies.
Monit ne se contente pas de relancer un processus disparu mais peut également surveiller sa consommation mémoire ou CPU. On peut alors fixer des seuils au delà desquels le noeud Mongrel sera redémarré (car les fuites mémoire existent aussi en Ruby).
Monit se couple également sans problème avec Capistrano/Webistrano, l’outil de déploiement que nous utilisons et qui nous permet de répartir les serveurs et traitements sur plusieurs nœuds.
mars 31st, 2009 at 8:21
Je vais regarder monit, mais j’ai des craintes sur qui surveille monit
God fait la même chose que monit (je pense) taille occupé en Mémoire, CPU, etc … Mais il tombait sur ma freeBSD en prod …
avril 1st, 2009 at 10:43
Sur nos serveurs Ubuntu, monit ne nous a jamais fait défaut. Il s’est montré totalement fiable et robuste.
En revanche, je n’ai aucune expérience sur FreeBSD. Je sais juste que c’est l’un des OSes officiellement supportés.
Bonne chance !
avril 16th, 2009 at 9:23
[...] Farcy Says: mars 31st, 2009 at 3:11 En effet, c’est une préoccupation essentielle en production que de s’assurer que les noeuds [...]