Surveillez eZ Publish avec JVMonitoring

posté par Jérôme Vieilledent, le 16/12/2009 17:06

Tags : monitoring , jvmonitoring , ezpublish , extension

Y a-t-il un site web dans la salle ?

Une fois le développement de votre site web achevé et mis en ligne, vous êtes vous déjà demandé :

Comment être sûr que tout fonctionne correctement sur mon site ?
Monitoring serveur

Et oui, une fois que le site est lancé, c'est le début de sa phase de production et nombre de problèmes peuvent survenir en fonction de la chance/malchance de chacun, du prestataire d'hébergement, de la position de la Lune... C'est aussi à ce moment que l'on peut se rendre réellement compte de la qualité de son développement et que les problèmes peuvent commencer (audience, charge du serveur, erreurs incompréhensibles).

Certes, il existe des plateformes très complètes permettant de monitorer des serveurs, voire même des fermes entières de serveurs, aussi bien au niveau physique (hardware) qu'applicatif (je pense notamment à Nagios ou Cacti ), mais on a souvent besoin d'un outil simple permettant de vérifier la santé de son application.

JVMonitoring : un outil parmi d'autres

JVMonitoring est une extension pour eZ Publish permettant de surveiller la santé de votre site via HTTP. Elle fournit notamment un module effectuant divers tests basés sur différents handlers (vous pouvez d'ailleurs en avoir un aperçu sur la page de monitoring de mon blog ). Chaque test affiche individuellement son statut (OK ou KO), avec un éventuel message d'erreur en cas d'échec. Si tous les tests sont effectués avec succès, le mot-clé OKMonitor est affiché en tant que statut général (le mot-clé est bien sûr configurable), et un code HTTP 200 est envoyé. Dans le cas contraire, c'est le mot-clé KOMonitor qui est affiché, associé avec un code d'erreur HTTP 500 .

Logo Site24x7

Associé à des services de monitoring comme Site24x7 (service de base gratuit), vous avez l'assurance d'avoir un site web qui fonctionne correctement et êtes avertis par e-mail, voire par SMS en cas de problème.

Par défaut, JVMonitoring fournit des tests de base portant sur :

  • La santé de la Base de données (connexion et requêtes basiques nécessaires).
  • L'accès HTTP externe depuis le serveur (utilisant le proxy s'il est configuré)
  • L'accès à la ligne de commande PHP
  • La disponibilité du système de redimension d'image (GD et ImageMagick , si ce dernier est activé)

Il est bien sûr possible de développer ses propres handlers afin de monitorer des parties plus spécifiques de votre application. Il suffit pour cela de créer une classe implémentant l'interface IJVMonitoringHandler . Cette interface définit plusieurs méthodes indispensables, et notamment la méthode isUp() qui permettra de savoir si votre composant est en bonne santé ou non. Pour plus de détails, je vous invite à lire la documentation de l'extension ainsi que les commentaires de son fichier de configuration .

Conclusion

JVMonitoring, bien que très pratique et répondant à la plupart des besoins en matière de monitoring, reste un outil simple et limité au protocole HTTP. Par ailleurs, depuis eZ Publish 4.1, si aucune connexion au serveur de Base de Données ne peut être effectuée, une exception eZDBNoConnectionException levée par le kernel et ne pouvant être attrapée empêche l'affichage du module (une erreur HTTP 500 est tout de même envoyée). Enfin, il n'est pas possible - pour le moment - de connecter cette extension aux systèmes de monitoring globaux cités plus haut (Nagios et Cacti entre autres). Pour cela, vous pouvez vous tourner vers l'extension eZSNMPd qui prend totalement en charge le protocole SNMP utilisés par ces systèmes.

Ces limitations mises à part, c'est une extension qui répondra aux besoins courants en matière de monitoring.

Related content

Commentaires

Mignon (par Karles)

Bonjour

C'est totalement centré sur l'application sans tenir compte de son environnement système et réseau. Or avec eZ tenir compte de l'application mais pas du système et inversement c'est l'impasse.

Avec jvmonitoring tout peux être OK sans pour autant que l'application soit fonctionnel, du fait des latences, surcharge, timeout, version de cache, conflit, etc... d'ou l'intérêt de monitorer l'intégralité de l'éco système.

Je vois pas la plus valus avec un validateur de "requirement" ?
D'ailleurs une application qui ce monitor elle même est la bonne approche ?

Karles

Limité mais utile malgré tout (par Jérôme Vieilledent)

Bonjour Karles
Oui, c'est limité et c'est d'ailleurs pour ça que je parle aussi de eZSNMPd, développé par Gaetano Giunta. Cette extension n'a absolument pas pour vocation de monitorer le système, mais l'application justement. Par ailleurs, je ne suis pas vraiment d'accord avec toi quand tu dis tout peut être OK dans JVMonitoring tout en ayant une application non fonctionnelle. Tout dépend des éléments que tu testes et comment tu les testes ...

eZSNMPd (par Karles)

eZSNMPd voila un truc mega bien, je ne l'avais pas vue passer
Merci

re: eZSNMPd (par gggeek)

@karles, ahiahiahi, tu me decois là...

A propos du monitorage de la "plateforme": je crois fermement que ce ne soit pas le job d'eZP de monitorer le serveur web ni la bdd. C'est pourquoi dans ezsnmpd tu ne trouveras pas des sondes spécifiques - mais si tu utilises le protocole snmp pour verifier l'etat de la plateforme, des sondes existent dejà sous la forme de plugins pour presque toute application "serveur" (ci compris apache et mysql).

Pour ce qui concerne les perfs plutot que des indics d'état, il est rudement plus dur de les mesurer sans tomber dans le panneau du "truc qui s'analyse soi meme". Il est p.e. plus facile de faire un GET de la homepage et mesurer le temps de reponse depuis le systeme de monitoring que de mesurer le meme temps depuis la sonde executée dans le serveur lui meme (a moins que le serveurs se fasse un GET tout seul, mais s'il est surchargé il aura du mal à se mesurer...).

Last but not least: executer les sondes via php cli plutot que via web a des avantages evidents: 1 - on peut mesurer la bdd à site web arreté, 2 - on peut mesurer le site web à bdd arettée (pbl mentionné par Jerome)

Pas tout à fait d'accord (par Jérôme Vieilledent)

Autant je vous rejoins pour tout ce qui est externe à eZ Publish et notamment la BDD (j'ai quand même voulu mettre un handler pour ça car j'ai déjà eu à faire avec des hébergeurs qui subitement te suppriment du jour au lendemain les droits DELETE), autant je ne suis pas d'accord pour tout ce qui est applicatif à proprement parler.
Cette extension propose des handlers basiques par défaut mais a pour vocation de s'étendre pour des parties spécifiques comme j'ai déjà eu à le faire sur Canal+ Foot (http://foot.canalplus.fr) et d'autres projets. Bien sûr, il est possible de le faire aussi dans eZSNMPd, mais le protocole SNMP est particulièrement lourd et, à mon avis, sur-dimensionné pour la plupart des tests à effectuer, surtout lorsqu'il s'agit de juste vérifier si des routes réseau sont ouvertes par exemple.

Ne rentrons pas dans un débat stérile , JVMonitoring est là pour effectuer un monitoring simple et permettre de développer facilement de nouveaux handlers applicatifs. Encore une fois, il n'est pas question ici de monitorer les parties hardware.

Voir le coté plugin (par Sébastien)

Pour ma part je suis plutôt d'accord sur le fait qu'il y a d'autres moyen plus évidents pour monitrer le hardware.

Néanmoins, coté applicatif, je trouve un intérêt à cette contribution dans la mesure où elle permet de développer ses propres handlers.

Très souvent je travaille sur des projets qui réalisent des imports/exports à partir ou vers des flux de toute sorte (XML, webservices, etc.) et dans ce cas là, je me verrais bien développer des handlers spécifiques à ces sources externes afin de checker leur bon fonctionnement.

Ainsi je suis prévenu dès qu'une des sources externes est down, et j'interviens sur le site.