Comme promis, voici des scripts de test à ajouter au système de surveillance développé dans les cours précédents :
Ping :
Écrire un script utilisant la librairie Net::Ping qui vérifie l'état de la connexion Internet de l'hôte en "pingnant" une adresse externe fiable
(www.yahoo.com est un excellent candidat).
FTP:
Automatiser la récupération du fichier /pub/CPAN/RECENT.html sur le serveur
ftp.cpan.org. Le fichier doit être récupéré une fois par jour.
Variante amusante à essayer : allez chercher le fichier /pub/CPAN/misc/japh !
Suggestion : consultez la documentation de Net::Ping et
Net::FTP sur le site du CPAN...
Voici les dates importantes pour la fin de la session :
Examen final : 13 mai.
L'examen porte sur toute la matière vu au cours de la session : notion de Perl, base de données ainsi que les divers modules vus au cours de la 3e partie du cours.
Remise du TP 3 : 18 mai.
La remise est à faire après la dernière scéance de laboratoire. Comme pour les autres TP, la remise doit se faire de 2 façons :
La copie papier doit être agrafé, comporter une page de présentation et être remise à temps : 5% par jour de retard. La copie électronique doit me parvenir avant minuit (23h59 !) le 18 mai faute de quoi le décompte des points de retard commence!
Les notes seront affichés via Omnivox dès que la correction sera terminée. Ceux qui désirent recevoir leur copie d'examen et de TP corrigé peuvent me remettre une enveloppe suffisament grande, pré-adressée et dûment "timbrée".
Voici la structure de la base de données...
Notez : dans le but de faciliter la correction, son nom doit être 'incident'.
Donc, vous aurez la table incident, dans la BD incident.
Mise-à-jour:
Le nom d'usager et le mot de passe sont, respectivement 'bob' et 'elvis'.
--
-- Table structure for table 'incident'
--
DROP TABLE IF EXISTS incident;
CREATE TABLE incident (
id int(10) unsigned NOT NULL auto_increment,
moment timestamp(14) NOT NULL,
nom_service varchar(30) NOT NULL ,
nom_script varchar(30) NOT NULL ,
niveau enum('debug','info','critique','urgent') NOT NULL default 'urgent',
a_ete_affiche enum('O','N') NOT NULL default 'N',
message text NOT NULL,
PRIMARY KEY (id)
) TYPE=MyISAM;
Une introduction à la génération de graphiques avec Perl, via le module GD::Graph:
DevChannel | Generating Perl graphs with GD::Graph
J'ai écrit un exemple simple de script qui peut s'insérer dans notre architecture.
Ce script vérifie l'espace disque disponible sur le système en "parsant" simplement la sortie de df -h, et avertie si l'espace occupé est plus grand que $MAX_PCT_UTILISE. Il ne fait qu'afficher (via warn) un message lorsque ce maximum est dépassé : la gestion de l'erreur dans la BD est laissé en exercice... :)
Voici le code en question :
#!/usr/bin/perl
#
# Test l'espace libre sur les systèmes de fichiers du système,
# via df -h
#
# On maximum, on
$MAX_PCT_UTILISE = 75;
print tester();
sub tester{
open (DF, " df -h|") || die "Erreur : $!";
@df = ;
close DF;
shift @df; # supprime la premiere ligne
foreach my $d (@df){
my ($fs, $sz, $utilise, $dispo, $pct, $montage) = split( /\s+/, $d);
$pct =~ s/%//;
if ($pct >= $MAX_PCT_UTILISE){
warn "Attention, $pct % du disque $fs utilise :\n\t Il ne reste que $dispo de libre sur $montage!\n";
## Dans le TP, on logue cette condition dans la BD...
}
}
}
L'énoncé du TP 3 est disponible. Du moins, en partie : comme le dit l'énoncé, certains éléments seront ajoutés au fur et à mesure que la matière nécessaire sera vu en classe.
Mise-à-jour!
On m'indique (avec raison!) que l'énoncé manque un peu de profondeur côté "portrait d'ensemble"... J'ai donc ajouté un peu de viande autour de l'os et décrit un peu mieux ce à quoi va servir cet outil. Voir l'énoncé!
Note : je vais vous fournir dans les prochains jours la structure de la base de données à utiliser : j'avais l'intention de vous laisser la faire, mais j'ai finalement décidé que ca serait plus simple que tout le monde ait la même base de départ.
Cet outil sert à surveiller un système (en l'occurence, le votre) et à garder un historique des situations "problématiques". Le tout fonctionne à l'aide de deux programmes : etat_sys.pl, qui nous donne une idée de l'état du système, et surveille_sys.pl, qui est activé chaque minute par cron et qui fait le travail de surveillance proprement dit.
Le script surveille_sys.pl utilise une architecture utilisant des "plugins" : le programme est exécuté chaque minutes et exécute les "plugins" appropriés, selon la pertinence (c'est décrit plus loin). Ainsi, chaque minutes, les plugins contenus dans le répertoire ~/.montmoniteur/minutes_1/ vont être exécutés et vont faire un travail de surveillance quelconque. Pour les minutes qui sont un multiple de 5, on exécute les plugins du répertoire ~/.montmoniteur/minutes_5/, idem pour 10 minutes, etc.
Les scripts de monitoring proprement dit seront à développer au cours des prochaines semaines en utilisant les modules Perl que l'on verra en classe. Ces scripts utiliseront des modules Perl "standard" pour faire toute sorte de vérifications (état de santé d'un service, lecture de syslog, etc.).
etat_sys.pl :
Par défaut, se connecte à la BD et vérifie si des erreurs ont été détectées (on rapporte les 5 dernières erreurs au maximum, par défaut), les affiches et marque les erreurs comme ayant déjà été rapportées. Si appelé avec le paramètres "rapport x.'' (x étant un nombre), affiche tous les détails connus des x derniers événements.
Exemple d'utilisation : on ajoute ce script dans les commandes exécutées au démarrage de notre session shell (dans .bashrc par exemple). Lorsqu'on ouvre un terminal, la commande nous informe d'une situation problématique :
Erreur : le service httpd ne répond plus!
[benoit@localhost benoit]$
surveille_sys.pl :
Activé par cron à chaque minutes. S'occupe de vérifier si des script de monitoring doivent être appelés.
Dans la tradition Unix, les configurations du programme sont situé dans un répertoire caché (~/.montmoniteur/). Dans ce répertoire, on retrouve :
D'abord, déterminer quels scripts doivent s'exécuter.
Ensuite, charger un-à-un les scripts en stockant leurs noms (pour pouvoir rapporter les erreurs d'exécution de script de la même façon qu'une erreur "normale", via la bd et etat_sys.pl, en nommant le script "coupable").
On exécute enfin, pour chaque script, la fonction $PACKAGE->tester(), qui fait le test fourni par le script.
Enfin,on appelle $PACKAGE->stockage_erreur() pour stocker les éventuels messages d'erreurs obtenus dans la BD. (MAJ Cette fonction pourrait être appelé implicitement dans la fonction tester() : c'est à vous de décider.)
Voir les exemples pour savoir comment faire ces opérations.
La liste des scripts de surveillance à programmer vous sera donnée au cours des prochaines semaines, selon les outils Perl qui seront vu en classe. Cet énoncé de TP est donc appelé à changer.
Pour l'instant, contentez-vous de faire exécuter des tests simples, qui vont par exemple afficher un "bonjour" ou autre chose qui fait votre bonheur ('Hello', par exemple.. ;oP ).
Certains ont des difficultés avec les tables qui comportent un champs "auto_increment". Je résume donc un peu leur utilisation :
Normalement, la syntaxe est la suivante :
create table patate (
id INT NOT NULL AUTO_INCREMENT,
tubercule varchar(100),
primary key(id)
);
A ne pas oublier :la spécification de "NOT NULL". Pour que l'auto_increment fonctionne, il faut que le champ soit marqué comme non-null. Lorsqu'on insères un nouvel enregistement, il faut alors ignorer le champ id, ou encore lui forcer un valeur de NULL :
INSERT INTO patate (tubercule) VALUES ('Monsieur');
INSERT INTO patate (id, tubercule) VALUES (NULL, 'Monsieur');
N'hésitez pas à utiliser les commentaires du site pour demander des précisions si vous avez encore des questions!
Vous pouvez aussi, bien entendu, m'écrire directement si vous préfèrez garder votre anonymat.. :)