Voici une procédure permettant de contrôler l’activité d’un serveur de messagerie postfix via Nagios / Centreon.

Pour cela nous allons utiliser le plugins check_mailstat.pl avec une petite adaptation du script afin de le rendre compatible avec la génération de graphe sous Centreon.

Le plugin check_mailstat.pl va récupérer depuis des données depuis mailgraph qui permet de générer des graphes via RRDTool

Tout d’abord, il faut installer Mailgraph sur l’hôte à superviser, ici une Debian.

Installation de Mailgraph

aptitude install mailgraph

Si l’installation ne vous a pas poser les questions propres au paramétrage, lancer :

dpkg-reconfigure mailgraph

Voici les questions et réponse à fournir :

Mailgraph doit-il être lancé au démarrage ? OUI

Fichier de journalisation à utiliser par mailgraph : /var/log/mail.log (à adapter)

Faut-il compter les courriels entrants comme des courriels sortants ? NON (J’utilise Amavis, donc j’ai choisi cette option, encore une fois à adapter.

Paramétrage et sécurisation de l’accès web Mailgraph

On va ensuite créer un un espace web dédié avec virtualhost afin de restreindre l’accès à l’interface web :

mkdir /var/www/mailgraph && mkdir /var/www/mailgraph/cgi-bin
chown -R www-data:www-data /var/www/mailgraph
cp -p /usr/lib/cgi-bin/mailgraph.cgi /var/www/mailgraph/cgi-bin/.

Voici un Virtual Host type avec prise en charge du ssl :

ServerName votre.hostname.com
 
ServerAdmin votre@mail.com
DocumentRoot /var/www/mailgraph
 
# Mise en place du SSL
SSLEngine on
SSLCertificateFile    /etc/ssl/web/mailgraph.crt
SSLCertificateKeyFile /etc/ssl/web/mailgraph.key
 
SSLOptions +StdEnvVars
 
Options FollowSymLinks MultiViews
Options +ExecCGI
AddHandler cgi-script .cgi
SSLOptions +StdEnvVars
 
# Restriction par mot de passe basique
AuthUserFile /var/www/mailgraph/.htpasswd
AuthGroupFile /dev/null
AuthName "Veuillez vous identifier"
AuthType Basic
 
require valid-user
 
# Restriction par adresse IP
AllowOverride none
 
Order deny,allow
Deny from all
Allow from 192.168.1.0
 
ErrorLog /var/log/apache2/mailgraph-error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/mailgraph-access.log combined

Créer donc le fichier /etc/apache2/sites-available/mailgraph puis l’activer :

ln -s /etc/apache2/sites-available/mailgraph /etc/apache2/sites-enabled/

Empecher l’indexation par les moteurs de recherche, on ne sait jamais :

cat /var/www/mailgraph/robots.txt
User-agent: *
Disallow: /

Ensuite générer le certificat SSL :

openssl genrsa -out mailgraph.key 1024
openssl req -new -x509 -days 3650 -key mailgraph.key -out mailgraph.crt

Déplacer les certificats/clefs à l’endroit paramétrer dans le Vhost

mv mailgraph.* /etc/ssl/web/.

S’assurer du bon paramétrage des ports apache (NameVirtualHost *:443)

cat /etc/apache2/ports.conf
 
NameVirtualHost *:80
Listen 80
 
# If you add NameVirtualHost *:443 here, you will also have to change
# the VirtualHost statement in /etc/apache2/sites-available/default-ssl
# to <VirtualHost *:443>
# Server Name Indication for SSL named virtual hosts is currently not
# supported by MSIE on Windows XP.
<strong>NameVirtualHost *:443</strong>
Listen 443
Listen 4433

/etc/init.d/apache2 restart

Génération de l’authentification Apache

htpasswd -c /var/www/mailgraph/.htpasswd admin

Redémarrer Apache, ce qui n’est pas forcément nécessaire, mais bon…

/etc/init.d/apache2 restart

(un dernier pour la route)

Voilà, vous devriez avoir accès à Mailgraph en SSL avec restriction par IP et Authentification basique Apache

Vous pouvez voir votre Mailgraph via l’url :

https://votre.hostname.com/cgi-bin/mailgraph.cgi

Installation du plugin chek_mailstat.pl

Installation des pré-requis

aptitude install unzip patch
unzip check_mailstat_plugin_v0.9.1.zip

Afin d’utiliser mailgraph, il est nécessaire de le patcher :

cd check_mailstat_plugin_v0.9.1
patch -b /usr/sbin/mailgraph mailgraph.patch

Là il faut attendre un peu afin que le fichier /var/tmp/mailstat soit créé. Le temps varie en fonction de la taille de votre fichier /var/log/mail.log

Attribuer les droits à l’utilisateur nagios

chown nagios:nagios /var/tmp/mailstat
chown nagios:nagios /var/tmp/mailstat.old

Tests et paramétrage

Test en local

Déplacer le script check_mailstat.pl là où se trouve tout les plugins

mv check_mailstat.pl ..

Vous pouvez lancer le script perl avec l’option « -h » pour afficher l’aide

./check_mailstat.pl -h

Voici comment cela fonctionne par l’exemple :

root@server:/usr/lib/nagios/plugins# ./check_mailstat.pl -w <strong>10</strong>:0:0:0:0:0 -c <strong>20</strong>:0:0:0:0:0
OK: <strong>sent:7.68</strong>   received:5.66   bounced:0.00   rejected:0.40   virus:0.00   spam:0.00   |<strong>sent=7.68</strong>   received=5.66   bounced=0.00   rejected=0.40   virus=0.00   spam=0.00

En gros, je déclenche un WARN dès que je suis à 10 mails envoyés et un CRITICAL dès que je suis à 20

Voici un autre exemple :

root@server:/usr/lib/nagios/plugins# ./check_mailstat.pl -w 0:0:0:0:0:<strong>10</strong> -c 0:0:0:0:0:<strong>20</strong>
OK: sent:7.68   received:5.66   bounced:0.00   rejected:0.40   virus:0.00   <strong>spam:0.00</strong>  |sent=7.68   received=5.66   bounced=0.00   rejected=0.40   virus=0.00  <strong>spam=0.00</strong>

Je déclenche un WARN dès que je suis à 10 spams envoyés et un CRITICAL dès que je suis à 20

On peut aussi tester plusieurs paramètres en même temps

root@server:/usr/lib/nagios/plugins# ./check_mailstat.pl -w 20:0:0:0:0:10 -c 30:0:0:0:0:20
OK: sent:7.68   received:5.66   bounced:0.00   rejected:0.40   virus:0.00   spam:0.00   |sent=7.68   received=5.66   bounced=0.00   rejected=0.40   virus=0.00   spam=0.00

Je déclenche un WARN dès que je suis à 20 mails ou 10 spams envoyés et un CRITICAL dès que je suis à 30 mails ou 20spams

Paramétrage

Il faut ajouter la commande afin que NRPE la connaisse :

vi /etc/nagios/nrpe.cfg

Ajouter la ligne ci-dessous :

command[check_mailstat]=/usr/lib/nagios/plugins/check_mailstat.pl -w $ARG1$ -c $ARG2$

Puis redémarrer NRPE

/etc/init.d/nagios-nrpe-server restart

Test depuis le serveur de supervision

Ici On demande à NRPE d’appeler la commande check_mailstat en posititionnant un WARN à 40 mails envoyés et un CRITICAL à 50

root@info59sup01:/usr/local/nagios/libexec# ./check_nrpe -H muscat.nexen.net -c check_mailstat -a 40:0:0:0:0:0 50:0:0:0:0:0
OK: sent:7.68   received:5.66   bounced:0.00   rejected:0.40   virus:0.00   spam:0.00   |sent=7.68   received=5.66   bounced=0.00   rejected=0.40   virus=0.00   spam=0.00

Si c’est OK, il faut mettre en place la supervision au niveau de Centreon

Installation niveau Centreon

Voici une façon d’utiliser Centreon. Personnellement, je l’utilise en me basant beaucoup sur les modèles pour n’avoir généralement que les arguments à renseigner lors de la mise en place de service, mais bon libre à vous

Les deux premiers points ne sont bien sur qu’à faire qu’une seule fois.

Je vais utiliser lancer mes vérifications via NRPE pour lancer ensuite en local le script check_mailstat.pl

Création de la Commande

Aller dans Configuration -> Commandes

Créer une sonde nommée check_nrpe_mailstat

Ligne de commande :

$USER1$/check_nrpe -H $HOSTADDRESS$ -c check_mailstat -a $ARG1$ $ARG2$

Exemple d’arguments :

!300:0:0:0:0:0!500:0:0:0:0:0

Modèle de graphique :

Mailstat (nous allons voir ensuite pour le créer)

Création du modèle de service

Aller dans Configuration -> Services -> Modèles

Créer un modèle nommé :

NRPE-MAILSTAT

Commande de vérification :

check_nrpe_mailstat (créer précédemment)

Ne pas donner d’argument pour laisser le paramètrage au niveau du service lui même

Création de la sonde de Service

Voici la partie qui serait à répeter en cas de déploiement

Aller dans Configuration -> Services -> Services par hôte

Créer un service nommé NRPE-MAILSTAT

Modèle de service :

NRPE-MAILSTAT

Arguments : (à adapter selon les besoins)

!40:0:0:0:0:0!50:0:0:0:0:0

Sauvegarder

Ensuite redémmarer le poller du Nagios concerné

Configuration -> Nagios

Serveur :

Votre_Poller

Cochez :

Deplacer les fichiers générés
Redémarrer Nagios

Et voilà, vous superviser ce qui circule au niveau de votre messagerie.

Vous avez même des graphiques sur les mails envoyés, enfin seulement sur la première donnée remontée à savoir les mails envoyés.

Il semblerait que les données de performances renvoyées ne soient pas tout à fait compatibles avec le format attendu par Centreon pour la génération de graphe.

En effet, seul le nombre d’éléments envoyés est graphé.

J’ai du modifier le script pour que cela fonctionne.

Graphe des données de Performances via Centreon

Modification du script pour gestion des données de performance par Centreon

Pour cela j’ai modifié le script Perl afin qu’il fournisse des données de performances comme attendu par Centreon

Voici ma modification ligne 97 :

Remplacer :

my $perfdata = sprintf "sent=%-6.2f received=%-6.2f bounced=%-6.2f rejected=%-6.2f virus=%-6.2f spam=%-6.2f", @stat_counter;

Par :

my $perfdata = sprintf "sent=%-6.2f;received=%-6.2f;bounced=%-6.2f;rejected=%-6.2f;virus=%-6.2f;spam=%-6.2f", @stat_counter;

Ceci permet de renvoyer des résultats de ce type :

root@server:/usr/lib/nagios/plugins# ./check_mailstat_new.pl -w 5:0:0:0:0:0 -c 10:0:0:0:0:0
OK: sent:3.12   received:6.25   bounced:0.62   rejected:0.00   virus:0.00   spam:0.00   |sent=3.12  ;received=6.25  ;bounced=0.62  ;rejected=0.00  ;virus=0.00  ;spam=0.00

Vous remarquerez l’apparition des points-virgules nécessaires au traitement de toutes les données de performances par Centreon.

Création du modèle de graphique

Nous allons maintenant créer un nouveau template de graphe pour accueillir et personnaliser les graphes qui vont être générés.

Aller dans Vues -> Graphiques -> Modèles

Choisir de dupliquer le modèle par défaut

Nom du Modèle : Mailstat (Celui qu’on a utilisé plus haut)

Label Vertical : Nombre

Vous aurez peut-être remarquer pour la création de la commande que j’ai utilisé ce modèle de graphique.

Création des Courbes

Aller dans Vues -> Graphiques -> Courbes

Pour rappel les données de performances sont :

sent=3.12  ;received=6.25  ;bounced=0.62  ;rejected=0.00  ;virus=0.00  ;spam=0.00

Cliquer sur Ajouter :

Nom du Modèle de courbes : Mailstat-sent

Nom de la source de données : sent ( Cela correspond au nom présent dans les données de performances)

Voici un screenshot pour le reste des paramètres :

Il faut répeter l’opération, en n’oubliant pas de personnaliser les couleurs, pour chaque élément de données de performances, soit :

sent
received
bounced
rejected
virus
spam

On retrouvera donc des courbes au nom : (N’oubliez pas Mailstat en début pour identifier plus facilement les modèles de courbes que vous souhaitez)

Mailstat-sent
Mailstat-received
Mailstat-bounced
Mailstat-rejected
Mailstat-virus
Mailstat-spam

Ce qui vous donnera au final un graphique de ce type :

Image:Centreon_graph_mailstat.png

EyesOfNetwork, solution de supervision libre basée entre autre sur Nagios, vient de sortir une nouvelle version qui est la 2.1.5.

EyesOfNetwork est une distribution incluant les éléments ci-dessous :

• GED (Generic Event Dispatcher) : gestion multi sites et sécurisée des évènements,
• NAGIOS : gestion des incidents et des problèmes,
• NAGIOSBP : gestion de la criticité des applications,
• NAGVIS : cartographie personnalisée de la disponibilité,
• CACTI : gestion des performances,
• WEATHERMAP : cartographie de la bande passante,
• BACKUP MANAGER : Outil de sauvegarde de la solution,
• EONWEB : Interface Web unifiée de la solution,
• EZGRAPH : Librairie d’affichage des graphiques,
• SNMPTT : Traduction des traps snmp,
• GLPI: Gestion de parc.

Pour mieux comprendre comment interagissent tous ces éléments, le mieux est d’avoir un schéma :

Maintenant que le décor est planté, et que vous avez une vision un peu plus complète de ce que réalise EyesOfNetwork, voici les nouveautés de cette nouvelle version :

• Support du NEB (Nagios Event Broker) Mklivestatus 1.1.4 en options (en vue de remplacer ndo2db)
• Ajout du plugin aggregate dans cacti
• Ajout de liens équipements et modèles dans la configuration nagios
• Rapports de configuration nagios (html et csv)
• Lien entre cookie eonweb et REMOTE_USER apache (/etc/httpd/conf.d/eonweb.conf)
• Mise à jour de la distribution GNU/Linux Centos 5.5
• Mise à jour de Php 5.2.13
• Mise à jour de Eonweb 2.1-1
• Mise à jour de Nagios 3.2.1
• Mise à jour de Ged 1.2.9
• Mise à jour de Nagvis 1.4.7 à noter que la 1.5 est sortie le 15 juin et propose d’ailleurs par défaut le broker Mklivestatus.
• Mise à jour de NagiosBP 0.95
• Mise à jour de Weathermap 0.97a
• Mise à jour de Backup-Manager 0.7.9
• Mise à jour de Glpi 0.72.4
• Mise à jour de Fop 0.95-0.3
• Et de nombreuses corrections de bugs

A l’occasion de la sortie de cette nouvelle version, voici l’interview de Michael Aubertin qui est le leader de la communauté EyesOfNetwork. (Merci à lui pour le temps qu’il m’a accordé)

- Peux-tu nous présenter la solution EyesOfNetwork ?

EyesOfNetwork est une solution de supervision dans la présentation et le choix d’architecture sont pensé pour être une aide au pilotage des systèmes d’informations. Dit comme cela, c’est un peu pompeux mais cela se traduit dans la réalité par une foultitude de petits détails permettant de gagner du temps grâce à la supervision et pas l’inverse. Dans cette optique, nous avons pris le parti de travaillé sur une présentation ITIL des outils afin de mieux parler le même langage. Pour profiter à plein de cela il faut malheureusement mettre son côté technophile de côté pour ce focaliser sur du simple et sur les utilisateurs, ou, ad minima les applications. Lorsque je dis simple, je vais illustrer mon propos par un détail technique, les plugins de check nagios. On nous reproche parfois de ne pas offrir immédiatement des mesures de performances liées au check Nagios. En effet d’autres excellentes solutions libres offrent cette facilité. Nous ne le faisons pas (même si dans les faits c’est possible) car cela implique deux choix impactant pour l’utilisateur. Premièrement, les plugins (ou scripts) deviennent beaucoup plus compliqué à lire et à écrire, or, pour qu’une supervision vive bien dans le temps il est impératif que son maintien en condition opération se fasse sans douleur. En ne permettant pas, à priori, la mesure de perf via Nagios, nous acceptons son action vers la mesure de disponibilité et rendons ses scripts de check extrêmement simple à produire et maintenir. C’est le fameux retour 0,1,2. Du côté de la DSI cela permet de spécialité la mesure de la disponibilité de la mesure de la capacité. Là encore, nous employons rarement le (le moins possible en fait) le terme de performance. En effet, même si Cacti est infiniment plus puissant pour ce boulot que ne pourra jamais l’être Nagios, il est primordial de bien faire comprendre que supervision ne veut pas dire console de débogage. Or, quand je vois sur le marché des outils propriétaire prétendant faire du monitoring de performance en temps réel, je dis « Oui, bravo, et votre supervision c’est quoi ? ». Donc à la question EON c’est quoi je réponds c’est un outil de supervision  sans plus de prétention que de se vouloir simple, pratique, ITIL et utile.

- Pourrais-tu nous présenter brièvement les membres de la communauté EyesOfNetwork ?

Avec plaisir! Que dire, nous sommes assez peu nombreux, pour l’instant, mais l’ambiance est fabuleuse que ce soit dans la core team ou dans la communauté au sens large. Je pense que c’est en partie parce que nous « commitons » facilement, et probablement aussi parce qu’on est des antithèses de stars et du coup les utilisateurs et les contributeurs nous abordent et nous enrichissent plus facilement.  Petit focus sur la core team. La core team c’est élargie d’un membre cette année je vais donc commencer par lui.

Sebastien Fernandez est un garçon formidable qui à tout compris au libre. Il ne se demande pas s’il peut coder, il offre se qu’il peut. Et on a vu arrivé un travailleur acharné qui test, démonte, remonte, anime le forum, produit des docs, conduit des POCs, bref, il ne code pas directement mais son apports et immenses. Il est extrêmement pertinent dans ses jugements techniques et cela nous permet d’opérer des choix plus facilement quant à l’avenir de tel ou tel outil. Du côté animation du forum, il est toujours d’une grande bienveillance pour les utilisateurs. Bref, c’est un p’tit gars qu’il est très bien!

Jean Philippe Levy est un grand pénible, mais c’est mon hémisphère droit. Il connait parfaitement les outils libres de supervision et à ce titre est un des architectes de la solution. Nos discussions sont souvent houleuses, puis, rapidement on trouve le compromis que nous proposons à la core team, et en fonction de leurs avis, on prend la direction en question. Au-delà de son action sur l’architecture, c’est un ami et il est rien de moins que le principal développeur de EON. C’est aussi lui que se gère une partie de l’infrastructure informatique du projet.

Jérémie Bernard est l’artiste de la bande (Même si JP joue merveilleusement de la gratte), et c’est mon hémisphère gauche. <Vous aurez noté que je n’ai plus que le reptilien à moi > Jérémie est le génie du C++ et de l’objet de la bande. Lorsque j’ai un truc tuchie à pondre, c’est vers lui que je me tourne. On fonctionne comme avec JP (mais en moins houleux ), on brainstorming comme des fous, j’explique ma vision, pourquoi et ou je veux aller (généralement à 5 ans). Là, il réfléchit et reviens vers moi avec une idée complémentaire. Après il commence à coder et on finit ensemble. En fait, je me contente presque de voir si je lis le code, mais comme il est humble il dit rien . Par exemple, notre bus logiciel, cœur de la solution, et partie d’une feuille de route que je lui ai donnée il y 5 ans et que nous avons réalisé par étape. Mais la trame, c’est le cas de le dire était posé il y a 5 ans. Idem pour le moteur de génération de document basé sur OpenOffice.org présent dans la solution.

Moi-même. Finalement je sers plus à grand-chose . Plaisanterie mise à part, je suis un des architectes de la solution,  j’essaie d’animer un peu la communauté, de parler un peu du produit. Je suis aussi toujours en mouvement et à l’affut sur l’organisation des développements aidé en cela par Jean Philippe pour poursuivre notre objectif.

- Est-ce qu’aujourd’hui EyesOfNetwork est seulement supporté par APX ou disposez-vous d’une communauté autre que les salariés d’APX ?

APX est notre principal sponsor. C’est aussi, pour des raisons de droits, le propriétaire de la marque. Yves Pellemans (Directeur Technique National) et plus généralement la Direction d’APX sait être extrêmement discret et ne nous impose absolument rien.  APX à bien compris nos motivations et se positionne sur un rapport gagnant / gagnant avec nous. Aussi, si il est exact que APX et à ce jour notre seul gros sponsor, APX n’est pas le sponsor. D’ailleurs, l’équipe est actuellement en relation avec d’autres représentants en Afrique, au Maghreb et au Moyen orient. Du côté de la communauté, 3 membres de la Core sont salariés d’APX (cela fait d’ailleurs partie du sponsoring) mais les autres contributeurs et membres n’ont pas de relation avec APX.

- Quels sont les besoins qui ont amenés à la création de ce bundle orienté supervision libre ?

De la question de la genèse… Sur ce genre de projet ou l’humain est au cœur de tout, il est difficile de dicté la vérité. Aussi, je me propose de vous livrer la mienne. Fin 2000, un groupe de trois personnes et moi avons discuté autour d’un bon café. Ce groupe comptait un expert réseau, deux experts du libre (coté système) et un expert en supervision. La conversation tournait autour d’un produit dont la traduction était en cours, NetSaint. L’ancêtre de Nagios. Il nous est apparu qu’il serait intéressant de produire une distribution orientée supervision. Expert ITIL de la première heure, Eric Vidal (l’expert en supervision du groupe) nous a donné une feuille de route des besoins. Les développements ont mis un peu de temps pour décoller car le travail est considérable. Tout c’est accéléré avec l’arrivé de Jérémie Bernard et Jean Phillippe Levy. En 2008, Grâce à Yves Pellemans, Didier Bouvet, Jean Pierre Filangi et la Direction du groupe (Merci encore à tous pour cette belle aventure :D), APX nous a accueilli, nous a fait confiance et tous les trois, nous avons pu relancer la dynamique. EyesOfNetwork était née. Depuis, la communauté s’est élargi, pour notre plus grand bonheur à d’autre membre extérieur à APX.

- On voit souvent un rapport aux méthodes ITIL, quels sont les briques couvertes par EyesOfNetwork ?

La version actuelle de EyesOfNetwork couvre:

· Un premier niveau du processus « Service Desk » (1/5)

· La complétude du processus « Gestion des Incidents » (5/5)

· Un bon niveau du processus de « Gestion des configurations » (3/5)

· Un bon niveau du processus de « Gestion des problèmes » (3/5)

· Un premier niveau de « Gestion des changements » (1/5)

· Un premier niveau de « Gestion des mises en production » (1/5)

· Un très bon niveau du processus « Gestion des capacités » (4/5)

· La complétude du processus « Gestion de la disponibilité » (5/5)

Dans l’avenir, nous allons nous attacher au service des processus de « Gestion des niveaux de service » et « Gestion des couts ».

- Quels sont les évolutions à venir de EyesOfNetwork ?

EyesOfNetwork va se décliner sur plusieurs briques spécialisées.

· EyesOfNetwork Supervision, peu ou prou l’actuel brique avec des améliorations au fils des versions

· EyesOfNetwork Exploitation, qui fera le focus sur l’exploitation et la production

· EyesOfNetwork Patrimoine, qui s’occupera du processus éponyme.

Dans l’immédiat, nous avons plusieurs travaux ouverts tel que:

· La hiérarchisation des évènements

· Un mash-up de rapports personnalisés

· L’intégration de Shinken

· La notion de GTI (TTO) en plus de la mesure des SLA

· La formalisation des contrats de services

· L’ajout OCS/GLPI complètement intégré (Base Exploitation).

· … et beaucoup d’autres POC.

- Quels sont les points forts selon toi de EyesOfNetwork ?

EON a les points forts de son point faible. Je m’explique. EON à une approche très pragmatique, simple et pratique, or, souvent la solution et comparé à d’autres par un personnel très technique. Ainsi, il arrive fréquemment qu’en première intention EON soit écarté pour une solution plus technologique. Par contre, dès que l’on parle SLA, Applications, modélisation d’organisation, multi-sites, multi-clients, la, EON devient vite extrêmement pertinent, que ce soit pour les techniciens, les administrateurs, les DSI et la DSIO. Autre exemple mais toujours aussi orienté simplicité et pragmatisme, la haute disponibilité et le PRA de la solution elle-même. Parlons PRA. La solution intègre son propre mécanisme de sauvegarde au travers de l’excellent BackupManager. Cela peut paraitre anecdotique mais cela permet à la fois la sauvegarde à chaud et une procédure rapide et fiable en cas de sinistre majeur. Du coté HA, EON supporte l’installation de packages cluster et peut ainsi fonctionné dans le cadre d’un PCS. Le cluster peut ou non (Via DRDB) possède un storage mutualisé de type SAN, iSCSI… On peut aussi, lorsque l’utilisateur souhaite le support de Red Hat Enterprise Linux*, installer EON sur une « vrai » Red Hat Enterprise Linux* le tout sans effort.

*LINUX est une appellation commerciale de Linus Torvalds. RED HAT est une marque déposée de Red Hat, Inc.

- Quels sont les besoins que vous pourriez demander auprès de la communauté du libre ?

Vaste question. Très franchement, cela risque de paraitre une réponse abstraite, mais c’est notre mode de fonctionnement. Les chantiers sont nombreux, le champ de compétence nécessaire est très large, et toute idée et toujours bonne à entendre et analyser. Aussi, tout contributeur capable de s’investir sur une tache qu’il aura demandé ou choisit avec sérieux sera toujours le bienvenue. Cela va de la traduction à l’animation en passant évidement par le code et la promotion. Les seuls impératifs sont, l’humilité, l’envie, le sérieux, et accepter d’être visible car nous tenons à valoriser chacun. C’est, selon moi, un point essentiel du paradigme économique et social qu’est le logiciel libre.

Liens utiles :

Site Officiel de EyesOfNetwork

Téléchargement et Changelog d’EyesOfNetwork

Centreon, solution de supervision opensource basée sur Nagios, vient de sortir en version 2.1.6

Cette nouvelle version est une version mineure afin de corriger quelques dysfonctionnements.

Centreon 2.1.6 bien que mineure, apporte une fonctionnalité qui je pense va être très pratique.

Il s’agit d’un système de vérification de bon fonctionnement de la solution de supervision.

Des indicateurs ont été placés en haut de l’écran à l’endroit visible sur la capture d’écran ci-dessous et permettront de connaître en temps réel l’état de son serveur.

Il s’agit de la partie Poller States :

Voici une explication des trois nouveaux éléments.

• Le premier concerne la latence des pollers qui indique si oui ou non les pollers ont du retard. Cela indiquerait un problème de performance.
• Le deuxième indique si les pollers sont démarrés
• Le troisième indique si les pollers sont toujours accessibles, superviser les pollers est logique, mais savoir si ils sont accessible peu importe l’endroit où l’on se trouve sera très pratique

Vous l’avez compris, cette nouvelle version reste une version mineure, mais je pense que même si ces avancées paraissent simple, il fallait y penser et ça sera vraiment pratique, surtout l’information concernant les retards de sa plateforme.

Ça m’est déjà arrivé, et cette évolution m’aurait fait gagner bien du temps.

Liens utiles :

Site Officiel de Centreon

Source de l’information

Voici un petit aide-mémoire pour installer le client Nagios NRPE sous Ubuntu avec les sources.

Plantons le décor :

J’ai un serveur de supervision Nagios  sous Ubuntu Server 9.10 que j’ai installé via les sources et j’ai besoin du plugin NRPE.

J’ai essayé d’installer nrpe (nagios-nrpe-plugin) via aptitude il me met des dépendances et me propose d’installer complétement nagios, ce qui me dérange quelque peu…

Il existe déjà plein de tuto pour installer NRPE sur le net, l’intérêt de celui-ci est en rapport avec une erreur concernant les fichiers Kerberos non trouvés sur la distribution Ubuntu Server.

Une dépendance possible est également le support du ssl :

# aptitude install libssl-dev

Tout d’abord téléchargeons les sources de NRPE

# cd /usr/local/src
 
# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz
 
# tar -xvzf nrpe-2.12.tar.gz
 
# cd nrpe-2.12

Si vous lancez juste le ./configure vous rencontrerez cette erreur :

checking for Kerberos include files… could not find include files

Ceci est valable sur les Debian également.

En regardant dans le fichier configure on voit qu’il recherche kerberos (krb5.h) dans le répertoire /usr/kerberos/include

Le fichier krb5.h se trouve dans /usr/include sous Ubuntu

# aptitude install libkrb5-dev

Donc lancer la commande :

# ./configure --with-kerberos-inc=/usr/include

Et là vous n’aurez plus cette erreur.

Puis lancer :

# make all
 
# make install
 
# cp init-script.debian /etc/init.d/nrpe
 
# chmod 755 /etc/init.d/nrpe
 
# mkdir /usr/local/nagios/etc
 
# cp sample-config/nrpe.cfg /usr/local/nagios/etc

Pensez à adapter votre configuration du fichier nrpe.cfg notamment le paramètre allowed_hosts

Pensez à ajouter le service nrpe au démarrage :

# update-rc.d nrpe defaults

Voila pour la petite astuce, perso je n’avais pas trouvé l’info sur la toile, pour Kerberos et Ubuntu, c’est pour ça que j’ai créé cet article

Cette article va vous présenter différentes solutions libres pour réaliser des tests de montée en charge, dit benchmark.

Cette idée m’est venu d’un commentaire que j’ai laissé sur le blog de Nicolargo concernant un article sur curl-loader

Mon commentaire énumérait différentes applications libres permettant de réaliser ces benchmarks et le suivi de la montée en charge.

J’ai donc décidé d’en faire un billet complet, j’avais déjà fait des billets sur Siège et Tsung

Les Applications libres de benchmarking :

Siege :

Donc pour rappel, Siege permet de faire des tests de montée en charge de vos appliactions web en simulant un grand nombre de connexions simultanées sur une ou plusieurs URLs données.
Siege rapporte le nombre totale de hits enregistrés, de bytes transférés, le temps de réponse, les accès concurrents et retourne le statut du serveur.
Siege supporte les protocoles HTTP/1.0 et 1.1, les méthodes GET & POST, les cookies, les transaction log, et l’authentification basique.

Site officiel de Siege

Tsung :

Tsung est un outils de test de performances permettant de réaliser des benchmark massif. Il est Multi-protocoles utilisant un système de plugin (HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP, SSL et XMPP/Jabber)

Et chose très importante, il permet de faire des scénarios. Les scénarios permette de simuler de la montée en charge mais non sur une seul url, mais via une succession d’action, par exemple, j’arrive sur la page d’accueil, je clique sur la catégorie « Administration », je choisi l’article « Test de montée en charge avec des logiciels libres ». L’activité de l’utilisateur et le taux d’arrivée peut être aléatoire en utilisant une notion de probabilité….

Ce qui est plus proche de la vie de ton application web qu’un nombre de requêtes simultanées sur une url.

Site Officiel de Tsung

JMeter :

Jmeter permet de simuler le comportement de plusieurs utilisateurs agissant de manière simultanée initialement sur une application Web.

Il est multi-protocole et peut désormais faire ses tests sur HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, POP3(S) and IMAP(S)

JMeter permet de faire des tests de performances, de robustesse, de charge et réalise des statistiques avec graphes à l’appui.

JMeter sur Wikipedia

Très bonne ressource pour l’utilisation de JMeter

Site Officiel de JMeter

AB – Apache Benchmark :

Très simpliste, il permet de simuler x utilisateur sur une url donnée

Curl-Loader :

Permet de simuler x connections simultanées sur plusieurs urls en même temps.

Il supporte les protocole HTTP et FTP.

Curl-Loader sur Nicolargo

Site Officiel de Curl-Loader

OpenSTA :

OpenSTA permet de faire des tests de montée en charge sur les protocole HTTP et HTTPS

Il a de gros inconvénients, d’abord il n’est disponible que pour la plate-forme Windows et est vraiment difficile à prendre en main.

Site Officiel de OpenSTA

CLIF Load Injection Framework :

Clif permet de faire des tests de performances d’applications web distribuées

Plusieurs injecteurs réparties (permet de simuler d’énormes charges) vont simuler des connections simultanées en mesurant les temps de réponse, des erreurs…

Des sondes déployées sur les serveurs hébergeant les applications à tester vont mesurer l’activité RAM, CPU, Disque…

Clif gère les scénarios et fonctionne en multi-protocole (TCP, UDP, TCP, DNS, HTTP(S), JDBC, JMS, DHCP, LDAP, SIP)

Site Officiel de CLIF

Voici un schema expliquant le fonctionnement de CLIF :

Selenium :

Selenium est une suite d’outils pour tester des applications Web.

Selenium dispose d’un Add-on pour Firefox qui va vous permettre de créer vos scénarios simplement en navigant sur l’application à tester, il y a un recorder qui enregistre votre navigation et il vous suffira de la rejouer x fois pour simuler une activité utilisateur réel.

C’est assez bluffant, on peut créer ses propres scénarios très facilement sans avoir à apprendre les commandes de l’application.

Selenium peut simuler via Selenium Remote Control (RC) différents navigateurs, plateformes et même language.

Selenium Grid  va permettre de mettre en place une architecture distribuées pour réaliser des tests en parallèle.

Voici un schéma expliquant son fonctionnement :

Site Officiel de Selenium

Funkload :

Funkload permet également des faire des tests de performances

Il gère également les scénarios grace à TCPWatch

Funkload génére des rapports HTML/PDF avec graphes.

Site Officiel de Funkload

TestMaker :

TestMaker offrant une version opensource et une version entreprise, il permet également de faire des tests de montée en charge.

Je le donne pour information, mais je ne détaillerais pas ici ces fonctionnalités.

Site Officiel de TestMaker

Httperf :

Httperf est également un outils pour mesurer les performances de vos applications HTTP(S)

Il peut être utilisé avec AutoBench et OpenLoad

Site officiel de httperf

Pour trouver une liste des solutions de tests opensource allez voir ce site :

OpenSource Testing Tools

La supervision de la charge des applications web :

Il est intéressant également de pouvoir jauger sur le long terme les temps de réponses de ses applications web via l’utilisation de scénarios également.

Il existe bien sur des solutions sur les solutions de supervision libres.

Cucumber-Nagios :

Cucumber-Nagios est un plugin Nagios qui permet de réaliser des scénarios de façon assez surprenant d’ailleurs.

Ceux-ci seront ensuite joués comme n’importe quel check Nagios et permettrons de suivre par exemple le temps de réponse.

Nagios-FR en parle, je vous laisse découvrir la façon de générer les scénarios avec Cucumber-Nagios

Site Officiel de Cucumber-Nagios

Zabbix :

La solution de supervision libre Zabbix comprennant gestion d’incident et de performance intégre par défaut une application permettant de réaliser des scénarios afin de tester des applications web et ainsi garder un historique des performances

Cette approche est très intéressante car combiné aux informations provenant de la supervision de base (charge CPU, RAM…) on pourra facilement identifié les sources de ralentissements.

Site Officiel de Zabbix

Et vous vous utilisez quoi pour faire vos tests de montée en charge ?

Comme la semaine dernière, voici ma nouvelle rubrique nommée bar à liens libres, qui me sert à échanger les liens qui m’ont intéressé cette semaine concernant les logiciels libres, comme je pourrais en discuter dans un bar.

Mon premier lien concerne un logiciel en ligne de commande permettant de tester les caractéristiques de débit, délais et gigue entre deux points d’un réseau: SJitter

Il a été fait par Nicolargo et est désormais disponible dans les PPA

Tux-Planet nous a fait un article intéressant pour expliquer comment tester les temps de réponse d’un serveur DNS. Il a fait également un article sur le monitoring d’appliaction Java avec VisualVM

Nagios-FR nous fait découvrir Shinken un Nagios core killer écrit en python qui aurait des performances bien plus accrues, affaire que je vais suivre de très prêt… Pour plus d’informations sur Shinken, je vous invite à aller consulter le site du créateur de Shinken qui est Français pour votre information… Un autre article m’a interpellé, mais celui-ci est un peu plus « vieux », mais tout aussi intéressant, il s’agit de Cucumber-Nagios qui permet de superviser des applications web comme si vous leur parliez. Ça fait nu peu science-fiction, je vous l’accorde, mais c’est réel…

Une initiative intéressante concernant le Green-IT qui est de recycler la chaleur des datacenters

Sur l’industrialiastion-php (mes collègues d’Alterway) vous verrez que PHP devient le troisième langage le plus utilisé selon TIOBE

J’en profite pour vous informer ou vous rappeller que j’ai créé un reddit sur les logiciels libres pour l’instant on est 24, et 2 à 3 personnes à y déposer des liens, principalement moi d’ailleurs…

Voici une petite interface web qui vous permettra de tester vos expressions régulières faite en Ruby, il s’agit de Rubular

Voilà pour cette édition hebdomadaire, en espérant que vous trouverez ces articles aussi intéressants que moi.

Bonne lecture et bon week-end.

Note : L’image illustrant cet article a été réalisée par Klafubra et est sous licence GFDL et provient de Wikimedia

Enfin bref, quelques fonctionnalités banales sans réel intérêt
Bien sur, je rigole, j’ai été surpris en rédigeant ces fonctionnalités, qui n’est qu’une traduction (excusez mon anglais) de la liste des nouvelles fonctionnalités présentées pour cette nouvelle version à cette adresse…
On voit d’ailleurs bien le tournant qu’est en train de prendre la communauté Centreon avec une des mises à jours majeures, qui est la gestion des fuseaux horaires, qui est l’utilisation de Centreon / Nagios dans des réseaux d’ampleur internationale.
Et bien, je suis vraiment impatient de pouvoir tester cette nouvelle version, même si je n’aurais pas vraiment d’occasion, ça me donne envie de monter un petit réseau perso pour test.
Je suis d’ailleurs curieux d’avoir un retour d’expérience sur cette nouvelle version Avis aux commentaires
Centreon dispose également depuis peu d’une nouvelle forge qui est une migration d’un système trac vers Redmine, qui à mon goût est plus user-friendly. Voir la news sur le blog de Centreon

Note : La numérotation de version sur le logo de Centreon n’est pas officielle, c’est juste moi qui ai rajouté le numéro de version sur le logo

Liens utiles :
Site Officiel
Téléchargement de Centreon 2.1RC²
Nouvelle forge de Centreon

* un plugin pour la supervision des performances de MySQL,
* un plugin pour la supervision de Postgres,
* la documentation des plugins de supervision disponible sur le wiki
* des corrections,
* …

Pour ceux qui ont pu aller au salon Solution Linux 2009, une présentation a été effectuée.
Plus d’informations sur la présentation, ainsi que les slides de celle-ci à cette adresse :
Webblog de Cedric Temple

Liens utiles :
La News sur le Webblog de Cedric Temple
Site Officiel de FAN : Fully Automated Nagios

A noter, qu’initialement, FAN contenait Nareto, mais je ne pense pas que cette nouvelle version l’utilise étant donné que Nareto n’est toujours pas compatible avec la version 3 de Nagios

NB : Cédric Temple vient de m’informer d’une mise à jour permettant de faire fonctionner Nareto avec Nagios 3, méa-culpa…