ServicesCheck - petit programme qui vérifie la disponibilité des services!
3 réponses
jb
J'ai =E9cris un petit programme qui permet de lancer des tests sur
diff=E9rents service (ftp, ssh , http ...), Il peut soit executer des
scripts externes soit utiliser des modules perl comme plugin.
Les status des diff=E9rents services sont pour l'instant OK/NOK pas de
WARN ou CRITICAL.
Les r=E9sultats sont enregistr=E9 sous forme de fichier pour ne pas =EAtre
d=E9pendant d'une base de donn=E9e SQL ou autre.
Il est aussi possible de g=E9n=E9rer des graphs rrd pour chaque service
(status sur 24h et temps de r=E9ponse sur 24h).
Pour l'instant l'interface web n'est pas vraiment finie et n'est pas
pr=E9sente dans le svn (script perl + AJAX like)
La version actuel tourne depuis 2 semaines en continue sur mon serveur
avec 26 test la plupart =E9tant des plugins nagios et deux autres des
modules perl. (25 test en thread, 1 en fork)
Je pourrais utiliser nagios aussi mais c'est un autre sujet :)
Le svn est http://www.ematome.com/svn/ServicesCheck/trunk/
Si quelqu'un =E0 le temps de lire un peu le code je suis ouvert =E0 tous
les avis, critique , paquet de bonbon, sucette et autre friandise.
PS: le module services::service pour l'execution des tests en forkant
me parais douteux surtout la communication inter processus.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Gaborit
À (at) 9 Jan 2006 18:19:41 -0800, "jb" écrivait (wrote):
Si quelqu'un à le temps de lire un peu le code je suis ouvert à tous les avis, critique , paquet de bonbon, sucette et autre friandise.
Après un premier coup d'oeil /rapide/, voici trois remarques :
- le code semble proprement écrit et modularisé, - certaines fonctions sont trop longues et sans commentaires, - les noms des modules ne respectent pas les règles Perl.
Pour le dernier point: les noms de modules en minuscules sont *réservés* pour Perl (pour les pramas comme 'strict' ou 'lib'). De plus, un sur-ensemble tel 'include' ne veut rien dire.
Il vaudrait mieux renommer vos modules par un nom générique (celui de l'application) suivi d'un nom explicite. Par exemple le module 'conf::secure' deviendrait 'ServiceCheck::ConfSecure'. Si le module est de portée plus large que celle de votre application, il faut (ou tout prévoir pour pouvoir) l'intégrer dans la distribution CPAN indépendament de votre application.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) 9 Jan 2006 18:19:41 -0800,
"jb" <joachim.basmaison@gmail.com> écrivait (wrote):
Si quelqu'un à le temps de lire un peu le code je suis ouvert à tous
les avis, critique , paquet de bonbon, sucette et autre friandise.
Après un premier coup d'oeil /rapide/, voici trois remarques :
- le code semble proprement écrit et modularisé,
- certaines fonctions sont trop longues et sans commentaires,
- les noms des modules ne respectent pas les règles Perl.
Pour le dernier point: les noms de modules en minuscules sont
*réservés* pour Perl (pour les pramas comme 'strict' ou 'lib'). De
plus, un sur-ensemble tel 'include' ne veut rien dire.
Il vaudrait mieux renommer vos modules par un nom générique (celui de
l'application) suivi d'un nom explicite. Par exemple le module
'conf::secure' deviendrait 'ServiceCheck::ConfSecure'. Si le module
est de portée plus large que celle de votre application, il faut (ou
tout prévoir pour pouvoir) l'intégrer dans la distribution CPAN
indépendament de votre application.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) 9 Jan 2006 18:19:41 -0800, "jb" écrivait (wrote):
Si quelqu'un à le temps de lire un peu le code je suis ouvert à tous les avis, critique , paquet de bonbon, sucette et autre friandise.
Après un premier coup d'oeil /rapide/, voici trois remarques :
- le code semble proprement écrit et modularisé, - certaines fonctions sont trop longues et sans commentaires, - les noms des modules ne respectent pas les règles Perl.
Pour le dernier point: les noms de modules en minuscules sont *réservés* pour Perl (pour les pramas comme 'strict' ou 'lib'). De plus, un sur-ensemble tel 'include' ne veut rien dire.
Il vaudrait mieux renommer vos modules par un nom générique (celui de l'application) suivi d'un nom explicite. Par exemple le module 'conf::secure' deviendrait 'ServiceCheck::ConfSecure'. Si le module est de portée plus large que celle de votre application, il faut (ou tout prévoir pour pouvoir) l'intégrer dans la distribution CPAN indépendament de votre application.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Paul Gaborit
À (at) Tue, 10 Jan 2006 10:14:12 +0100, Paul Gaborit écrivait (wrote): [...]
*réservés* pour Perl (pour les pramas comme 'strict' ou 'lib'). De ~~~~~~
[...]
Il faut lire 'pragmas'... Désolé.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Tue, 10 Jan 2006 10:14:12 +0100,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
[...]
*réservés* pour Perl (pour les pramas comme 'strict' ou 'lib'). De
~~~~~~
[...]
Il faut lire 'pragmas'... Désolé.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
