Dans un récent article Comment être productif avec 5 écrans (en même temps, ils sont tous récents vu l’âge de ce blog), je vous parlais de mon écran dédié au monitoring. Voici donc le billet tant attendu. Mais je vous préviens, il risque d’être inintéressant :-)
L’hébergement des différents sites de ma société (en somme, VDM et ses déclinaisons linguistiques) est entièrement géré par SD France au niveau matériel, et par votre serviteur au niveau logiciel / administration système. La question qui s’est donc rapidement posée une fois que tout était mis en place fut celle de la surveillance de toutes ces machines, autrement appelée le monitoring.
Les premiers termes qui viennent à l’esprit lorsque l’on parle de monitoring sont Nagios, MRTG, et autres RRDTool, qui sont les outils les plus populaires dans la surveillance en réseau. Pour ma part je les ai trouvés bien trop complexes pour les quelques données dont j’avais besoin au quotidien, c’est pour cela que je me suis orienté sur une solution maison que je vais vous décrire ci-dessous.
Côté serveur
Même si tout un écran peut sembler important niveau espace, lorsque l’on parle de 27 serveurs à monitorer individuellement, il faut se montrer efficace. Il a donc fallu identifier les points-clés à surveiller. J’ai choisi les suivants :
- Etat de la réplication MySQL : Point névralgique évident lorsque l’on parle de réplication circulaire master-master. Si un des serveurs ne réplique plus, toute la boucle est endommagée immédiatement.
- Secondes de retard MySQL : Ce n’est pas précisément le temps de retard d’une réplication par rapport à son maître, il s’agit plus précisément de la différence entre le temps actuel et l’heure indiquée sur le log que l’esclave est en train de répliquer. Cela reste cependant un bon indicateur de l’état de santé de la réplication.
- Connexions Apache : Permet de savoir en permanence les connexions à un instant t sur le cluster Web, ainsi que les types de connexions (lecture, écriture, slot inactif).
- Statut du serveur Memcache : Le serveur memcache est assez sollicité pour stocker de manière centralisée les sessions PHP du cluster, ainsi que certaines données des sites.
- Modifications sur le FTP : Plusieurs personnes travaillant sur le FTP, il est parfois utile de savoir quels ont été les derniers fichiers modifiés lorsque survient un problème inexplicable par le simple état des machines. J’ai codé un script qui établit automatiquement un diff du fichier uploadé versus le fichier original, pour plus de lisibilité.
Une fois ces points identifiés avec succès, il a fallu coder les agents qui enverront les données à un serveur central (j’ai dédié un serveur au monitoring). Ces agents envoient actuellement les informations toutes les 5 secondes via le réseau local sur une interface VLAN. Je les ai codés en PHP ou en Perl selon l’inspiration du moment. C’est un serveur Web qui récolte les données et peuple une base MySQL, mais peu importe le langage du moment que les variables sont renseignées dans la base de données.
Côté client
Ma base se peuple maintenant à la vitesse de la lumière (ou du cuivre, selon le degré de poésie). Il faut maintenant développer l’interface qui affichera les données en temps réel sur mon écran de droite.
Par pure déformation professionnelle, j’ai encore tâté de l’HTML. Les connexions à Apache que vous voyez ci-dessus ainsi que les secondes de retard MySQL plus bas ont été réalisées via l’excellente librairie Flash Amcharts que j’avais déjà utilisée auparavant. Cette librairie crée des graphiques en Flash à la volée, au moyen de fichiers XML ou CSV, et permet aussi de rafraîchir ses données à intervalles de temps réguliers.
Concernant les données qui ne nécessitent pas de vision en fonction du temps, j’ai tout simplement utilisé de l’AJAX (avec jQuery) qui permet par exemple de rafraîchir l’état de la réplication MySQL et d’afficher l’erreur explicite en cas de panne. J’ai aussi utilisé cette technique pour afficher les dernières modifications du serveur FTP.
Enfin, comme le résultat donne une page Web, j’avais besoin qu’elle se comporte comme une véritable application, afin d’éviter qu’elle se ferme lorsque je devais redémarrer Safari, ou tout simplement pour pouvoir placer la fenêtre de manière permanente en plein écran sur la droite. J’ai utilisé comme à chaque fois Fluid qui permet tout cela, et même bien plus avec ses librairies Javascript intégrées (vous pouvez par exemple mettre des badges ou des notifications Growl très simplement).
Et quand t’es dehors ?
Avoir un smartphone est forcément indispensable, dans mon cas c’est un iPhone. Vous n’êtes pas sans savoir qu’il ne gère pas le Flash, et quand bien même il le gérerait, ce serait trop lourd pour vérifier d’un coup d’oeil l’état de mes serveurs en Edge ou en Wap. J’ai donc codé une page HTML avec les entêtes HTML qui vont bien pour que l’iPhone considère ça comme une application à part entière :
<meta name="robots" content="noindex" />
<meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=no;"/>
<meta http-equiv="cache-control" content="no-cache"/>
<meta name="format-detection" content="telephone=no" />
<meta content="yes" name="apple-mobile-web-app-capable" />
<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="apple-touch-icon" href="/mgmt.png"/>
<script type="text/javascript">
addEventListener(
"load",
function() {
setTimeout(hideURLbar, 0);
setTimeout('window.location.reload(true)', 5000);
}, false
);
function hideURLbar() { window.scrollTo(0, 1); }
</script>
La page se rafraichit automatiquement toutes les 5 secondes pour me permettre de supprimer totalement la barre d’adresse de l’écran de contrôle.
J’ajoute à côté du screen une autre application qui s’appelle HostMonitor [iTunes], très pratique pour simplement tester des ports sur des machines distantes, le tout sous forme de groupes. Utile si vous voulez juste jeter un oeil sur l’état de santé de votre réseau.
Le monitoring version iPhone, et HostMonitor.
Un autre outil que j’utilise (mais moins souvent), c’est iStat. Cette application se présente sous la forme d’un client iPhone et de serveur à installer sur tous les ordinateurs que vous souhaitez monitorer. L’avantage est qu’il marche sur Linux aussi bien que sur Mac, avec seulement un port TCP à ouvrir sur chaque serveur. Le détail des paramètres système est paramétrable.
iStat en action.
Concernant l’installation sur des serveurs Linux, le code source est disponible sur Google Code. Une bonne âme a créé un paquet Debian à partir de ces sources, elle s’appelle Marius (iStat My Linux on My Phone) et le lien se trouve en bas de son article. Un coup de dpkg -i plus tard et vous avez un serveur iStat sur votre Debian (pensez aussi à éditer le /etc/istat.conf si vous ne souhaitez pas que tout le monde connaisse vos stats).
Voilà pour le billet promis, désolé si j’ai mis un peu de temps à le rédiger, et pour la consistance finale de l’article, mais j’ai eu du mal à trouver une meilleure présentation. Comme d’habitude, si vous avez des questions, je tenterai d’y répondre avec mon humble expérience.
Jérémy — le 21 décembre 2009 à 11:40
J’aime beaucoup cette façon de faire ! Je vais tester les applis iPhone pour surveiller quelques serveurs dont j’ai la charge.