Monitorez vos serveurs, ça sauve la vie !

Dernièrement, le serveur de Flo était down, et l’un des serveurs de ma boîte a été down à peu près pendant la même période (malheureuse coincidence que ça soit arrivé à quelques jours d’intervalle, mais rien à voir).

C’était dû à quoi ? Pour Flo, il n’avait pas renouvelé, et le mail est arrivé sur une de ses anciennes adresses qu’il ne regarde plus. Pour moi c’était le serveur AWS utilisé par notre hébergeur SaaS qui était down et a dû être relancé.

Ce genre de choses, ça arrive, c’est normal. Par contre, le problème, c’est combien de temps vous allez mettre à réagir.

Dans nos cas, c’est pas tip-top : Flo a appris que son serveur était down par moi, quand mon back-up weekly (vers son serveur donc) a échoué. Ca devait faire déjà quelques jours qu’il était coupé. Moi, j’ai eu une remontée d’une de nos apps qui se prenait une 504, et vu qu’on l’utilise le serveur tous les jours, ça fait moins de 24H de down. Mais je ne peux pas dire quand exactement c’est arrivé (ni pourquoi, mais ça c’est une autre histoire, et vu que je suis en SaaS ce n’était sûrement même pas de mon ressort).

J’ai déjà présenté Jenkins, qui me sert entre autre à faire des back-ups, optimiser des images, monitorer des quotas, build des applications … Et bien on va lui rajouter une fonction : vérifier que nos serveurs et les sites qui tournent dessus sont bien joignables.

Alors évidemment, pour que ça marche, il faut que Jenkins soit sur un autre serveur que celui que vous voulez monitorer, sinon ça sert à rien. Si vous n’avez qu’un serveur, vous pouvez facilement installer Jenkins sur un vieux PC chez vous, ça marche très bien aussi (dans ma boîte, on a un Mac Mini dédié à ça, surtout pour le build des apps).

Commençons par le script : il y a plusieurs moyens de vérifier qu’un serveur est en ligne : le plus connu, c’est le ping, dont le but premier est de savoir le temps qu’il faut pour joindre le serveur, mais qui est majoritairement utilisé uniquement pour savoir si un serveur est joignable (ou pour savoir si la connexion marche).

Ca garantit que le serveur est joignable, mais pas qu’il marche correctement : pour savoir ça, il faut récupérer une page (les outils les plus connus pour faire ça sont curl et wget), et vérifier que le statut de réponse HTTP est bon : vu qu’on teste une page Web, ça doit être le code 200 (pour une API, il est possible d’avoir d’autres statuts de succès, un succès commence toujours par 2, par exemple 201 ou 204)

Enfin, vu que c’est un serveur dédié, je préfère aussi vérifier que les DNS sont bons, avec dig (il y a aussi host, mais la sortie est moins pratique à utiliser dans un script). Les DNS, c’est ce qui permet d’associer un nom de domaine (motive-moi.fr) à une IP (213.246.58.27), derrière laquelle on peut trouver le serveur. Si les DNS ne sont pas bons, vous serez redirigé vers un autre serveur, donc un autre site.

Voici le script, en exemple je le fais sur motive-moi.fr, vous pouvez facilement changer vers un autre site :

URL=motive-moi.fr
FRONT_PAGE=http://www.motive-moi.fr/
EXPECTED_IP="213.246.58.27"
ping -c 3 ${URL}
DNS_IP=$(dig +short ${URL})
FRONT_PAGE_HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" ${FRONT_PAGE})
if [ $DNS_IP != ${EXPECTED_IP} ]; then
	echo "DNS error, doesn't match expected IP ${EXPECTED_IP}"
    exit 1
fi
if [ $FRONT_PAGE_HTTP_CODE != "200" ]; then
	echo "Server error, front page doesn't return a 200"
    exit 1
fi

Ensuite, il faut l’exécuter périodiquement, j’ai choisi de le faire toutes les 10 minutes, histoire d’être rapidement au courant de problème sans non plus trop surcharger le système, ça donne niveau CRON : H/10 * * * *

N’oubliez pas d’activer les notifications, et voilà, la prochaine fois que votre serveur sera down, vous en serez informé dans les 10 minutes maximum !

Vous avez d’autres suggestions pour améliorer le script ? Laissez-nous un petit commentaire !

Avant de finir l’article, évidemment je ne peux pas ne pas vous parler des services dédié à ça qui existent. C’est un peu plus long à mettre en place qu’un simple job Jenkins, mais ça apporte énormément de fonctionnalités. Si vous voulez faire tourner sur votre propre serveur, Flo m’a parlé de Monit et Nagios (je vais sûrement tester Monit). Si vous cherchez plutôt du SaaS, les plus connus sont New Relic et Pingdom (c’est pas donné si vous hébergez votre petit serveur par contre, c’est plutôt orienté pros, quand vous ne pouvez pas vous permettre que votre site soit down une seule minute)

A propos :
François Dupayrat Lead Développeur Lead Développeur chez Auticiel, curieux et maker sur mon temps libre ! Ma passion du moment change souvent.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *