L’une des grandes nouveautés de cette version c’est qu’elle propose l’installation d’une supervision distribuée avec un serveur FAN central, base de données et collecteur.

La version 2.1 est également composée de :

• Nagios 3.2.3
• Centreon 2.1.13
• NagVis 1.5.8
• Les plugins officiels de Nagios 1.4.15
• L’ajout du thème Vautour personnalisé FAN pour les CGI de Nagios

Je vous invite à découvrir le changelog complet de cette version sur le site du projet.

Le projet est maintenu entre autres par Olivier LI-KIANG-CHEONG qui a repris le lead du projet et je vous invite vous reporter à ces articles pour plus de détails :

• L’annonce officielle
• L’annonce sur le blog de lkco

Dernièrement, le projet F.A.N s’est considérablement ralentit par faute de disponibilité de ses développeurs mais surtout de son leader Cédric TEMPLE. Ayant peu de temps à accorder au projet ces derniers temps, Cédric a pris la décision de céder la main à Olivier LI-KIANG-CHEONG qui faisait partie de l’équipe des développeurs.

Olivier LI-KIANG-CHEONG prévoit de sortir à court terme une nouvelle version de F.A.N et de publier une future roadmap pour le projet afin de relancer et rediriger le développement.

Pour de plus amples informations, je vous invite à lire l’annonce de Cédric TEMPLE sur son blog
Blog Cédric Temple : LKCO devient le nouveau responsable de FAN Fully Automated Nagios

Toute la communauté souhaite un bon courage à Olivier LI-KIANG-CHEONG dans sa tâche de reprise du projet et l’annonce d’une Roadmap riche en surprise.

La version 1.3 sortie hier nous apporte un joli lot de fonctionnalités et pas seulement que sur le Core. Il est annoncé une liste assez conséquente de mise à jour, une compatibilité avec l’IPv6 et un élargissement de l’éventail de compatibilité du Broker avec des bases de données comme MySQL, PostgreSQL et même Oracle pour les plus sceptique de l’open source. Icinga annonce aussi que sa nouvelle interface est plus optimisé en temps de réponse.

Voici la liste des changements apportés par la version 1.3 :

Changelog Icinga v1.3

Pour télécharger la version 1.3 d’icinga c’est ici :

Cette sortie s’accompagne d’un petit effet d’annonce : des webservices permettant de piloter la solution seront également de la partie à l’avenir !

Téléchargement : http://www.centreon.com/Community-Extensions/centreon-clapi-overview.html

Documentation : http://forge.centreon.com/wiki/centreon-clapi

Source : http://blog.centreon.com/

Cette version est essentiellement une version intégrant des correctifs qui peuvent être classés comme mineurs : aucune alerte de sécurité et aucun bug bloquant n’a été signalé.

L’équipe Monitoring-fr en a déjà parlé, mais comme l’audience est chaque jour plus importante, voici un petit rappel.

EyesOfNetwork, encore appelé EON, (pour faire classe dans les salons vous pouvez prononcer ï-aune ) est une distribution Linux crée pour être une appliance logiciel orienté supervision ITIL. Cette application se veut simple, pragmatique et utile.

Autrement dit, 99,9% de son administration/utilisation se fait via le Web et vous n’avez pas besoin d’être expert en solution Libre et autres linuxerie shello-hèssehèssehacho-perlienne pour l’utiliser.

Par rapport aux autres solutions libres, non moins excellentes, nous avons opéré plusieurs choix différenciant parmi lesquels on peut citer:

• Le respect et l’orientation de l’ergonomie web de l’interface vers l’ITIL
• La non intrusion dans le code des outils que nous embarquons
• La spécialisation des outils pour chaque processus ITIL (ex: Nagios pour la dispo, Cacti pour les perfs,…).
• Une séparation complète des plugins orienté disponibilité et capacité. Cela rend les check infiniment plus simple à produire pour n’importe qui et permet une surveillance plus simple des applications vu de l’utilisateur.
• La distributivité au travers d’un bus logiciels libre « maison » souple et performant (on le dit.) écrit en C++
• Une orientation évènementiel.
• Un reporting indépendant des outils dessous (Nagios, Cacti, NetSNMP….)
• La meilleure adaptabilité possible aux organisations (c’est l’outil que s’adapte au SI par l’inverse).
• Et plein d’autres petits détails qui remplissent de joie de nos utilisateurs, ce qui nous ravit

Stabilisation vers la 2.2

La communauté EyesOfNetwork est très heureuse de vous annoncer la sortie de la version 2.1.5 de EyesOfNetwork Supervision. Cette version apporte quelques petites nouveautés dont on parlera un peu plus bas, mais a surtout vocation à stabiliser la version 2.0 tout en préparant la version 2.2.

Coté nouveautés

Parmi les nouveautés marquantes on peut noter:

• L’ajout de mklivestatus en option pour remplacer ndo2db. Rappelons d’ailleurs que la distributivité de EON s’opère via notre bus logiciel GED. Mklivestatus et NDO ne sont utilisé que comme backend non critique pour Nagvis par exemple. Le chainage et la centralisation des EONs se faisant selon son choix, pour modéliser l’organisation ou pour répondre aux distance géographique, GED étant capable de faire du synchrone, de l’asynchrone, du VPN et le tout en SSL « proxy passthrough » et ceux, même avec un ISA server de Microsoft(tm).
• L’ajout d’une capacité d’export de la configuration de Nagios en CSV ou en HTML. Ceci permet à l’administrateur de la solution une certaine facilité de lecture en dehors du mode graphique.
• La mise à jour de nombreux composant dans leur dernière version disponible au moment du build.
• L’ajout de l’excellent plugin aggregate pour Cacti. Ce nouveau plugins permet d’agréger des graphs dans un seul. C’est particulièrement utile pour la vision des capacité des Clouds et autre environnement virtualisé.

Les mise à jour

Concernant les mise à jour et les patchs, en voici la liste (normalement exhaustive ):

UPDATE : Centos 5.5
UPDATE : Php 5.2.13
UPDATE : Eonweb 2.1-1
UPDATE : Nagios 3.2.1
UPDATE : Ged 1.2.9
UPDATE : Nagvis 1.4.7
UPDATE : NagiosBP 0.95
UPDATE : Weathermap 0.97a
UPDATE : Backup-Manager 0.7.9
UPDATE : Glpi 0.72.4
UPDATE : Fop 0.95-0.3
FIX : NagiosBP langue par défaut dans IE
FIX : Nagvis timezone error
FIX : Import Fruity Host-Hostgroups
FIX : Lilac création de commandes sans nom
FIX : Evènements résolus 2 max ack time
FIX : Snmpv3 communauté pas obligatoire
FIX : Erreurs lors de l’import csv
FIX : Erreurs lors de la création des contacts via eonweb
FIX : Tris par ordre alphabétique dans lilac
FIX : Libgcrypt warning: missing initialization
FIX : Tri par durée des acquittements dans les évènements historisés
FIX : Tri par template dans l’exportateur nagios vers cacti
FIX : Communauté snmp pré-définie dans l’exportateur nagios vers cacti
FIX : Suppression des stats dans syslog-ng

En route vers le futur…

Actuellement plusieurs chantiers sont ouverts.

Tout d’abord de généreux contributeurs (vraiment merci à eux) sont en cours de concoctions de nouvelles documentations sur l’usage et l’installation de EON. Ces travaux sont l’œuvre de Sebastien Fernandez et Anthony Leduc. Les docs terminés trouveront leur place bientôt dans la section adéquat de notre site.

Ensuite Jean Gabès nous fait l’honneur et l’amitié de travailler actuellement à un portage de Shinken en lieu est place de Nagios. C’est pour l’instant un POC (Proof Of Concept) et j’espère proposer le résultat de ces travaux en option dans la V 2.2. C’est important pour nous car nous opérons le plus possible de check Nagios en mode Actifs. Nous faisons cela car la charge de maintenance de l’outil de supervision doit être la plus faible possible. Ainsi par des checks ‘full active’ aucune action n’est requise sur les équipements à superviser. Le problème et que Nagios est trop peu optimal pour permettre une surveillance d’un gros SI dans cette configuration. Aujourd’hui on contourne ce problème en utilisant GED mais cela impact la lisibilité de l’architecture. Shinken, grâce à son haut niveau de performance renforcera de fait la pertinence de notre outil.

Dans le même esprit Jean Philippe Levy et moi même travaillons actuellement à une meilleurs prise en charge des WMI. En complément de SNMP cela nous permettra d’étendre nos capacités de check actif sans passer par la case NRPE, NSC++… etc. Et donc, moins de travail EON pour l’administrateur qui se libèrera ainsi du temps pour amélioré la qualité de service du SI ou en proposé de nouveaux. Ces travaux s’appuient sur des portions de codes issus entre autre du travaille remarquable fournit par l’équipe de Samba4.

Pour optimiser les rapports des centres de services, nous allons ajouter la notion de TTO (Time To Own). Cela permettra en plus du SLA de mesurer l’effort produit par les équipes dans la prise en charge de chaque incidents voir, des problèmes (au sens ITIL bien sur).

Coté exploitation, nous espérons pouvoir pousser plus avant l’utilisation de OCS et de GLPI couplés à la notion d’évènement.

Enfin, nous avons toujours à l’esprit la construction du Mashup AJAX pour créer vos templates XSL/XML de génération des rapports en ligne. Je rappelle que EON possède un générateur de rapport directement au format bureautique. Cela permet d’éviter les extractions CSV puis génération de Graph puis couper/coller dans les docs de comité de pilotage. Cela fait perdre du temps en préparation pour peu de valeur ajouté pour les admins. A ce jour, pour générer un nouveau type de rapport, il faut manuellement écrire son « patron » XSL/XML. Ce n’est pas très dur car un exemple est fournit mais c’est rebutant pour un non développeur. Aussi, nous espérons un jour trouver suffisamment de temps pour coder ce projet qui est un gros morceaux. Si quelqu’un est tenté, par un coup de main la dessus, faîtes nous signe, on est plus que preneur . Les compétence requises sont (Java, C++, XSLt, XML, PHP, AJAX, API UNO et FOP). C’est donc un super plan pour un bon projet d’étude d’école d’ingénieur en informatique qui n’aurait pas d’idée de projet .

J’espère ne rien avoir oublié qui aurait pu vous être utile pour découvrir la solution.

Je remercie très chaleureusement l’équipe Monitoring-fr de nous offrir cette tribune.

L’équipe de Shinken vient d’annoncer la première version officielle de son outil. Cette version 0.1 n’est pas encore pleinement testée et n’est donc pas destinée à arriver aujourd’hui sur vos environnements de production, mais devrait envahir les environnements de qualification sous peu aux vues des fonctionnalités proposées qui sont tout bonnement impressionnantes.

Rappel sur ce qu’est Shinken

Le projet Shinken consiste en une refonte complète du cœur de Nagios en Python, lui apportant une nouvelle architecture plus souple et plus facile à maintenir que le daemon monolithique actuel. Se basant sur une vue Unix, l’architecture se compose de daemons simples qui coopèrent afin de proposer les mêmes fonctionnalités que Nagios, voir plus.

Ainsi en se basant sur la configuration actuelle de Nagios, ainsi que ses innombrables sondes, Shinken est capable de remplacer Nagios dans la supervision classique :

• vérifications des états SOFT/HARD
• gestion des dépendances réseaux et logiques (applicatives)
• gestion des actions correctrices
• supervision active et passive
• vérification de la fraicheur des informations dans le cadre de la supervision passive

Mais il est également possible d’obtenir bien plus qu’un Nagios standard :

• supervision distribuée hautement disponible très facile à mettre en place, et de manière intégrée à la configuration globale
• gestion des noms en UTF-8
• presque 5 fois plus de performances que le Nagios classique
• Multiplateforme : tourne nativement sur GNU/Linux et Windows. Il est même possible de mixer les deux dans une même architecture!

Ces innovations sont dues principalement au choix de Python qui a permis d’avoir une nouvelle architecture très facilement. Les différents éléments de celle-ci sont :

• Arbiter (Arbitre) : il est en charge de lire la configuration et de l’envoyer aux autres éléments. Il est capable de découper la configuration globale de l’utilisateur afin d’en faire des petits morceaux qui seront pris en charge par les autres éléments. Ceci permet d’avoir une supervision distribuée de manière automatique. C’est également la tour de contrôle de l’ensemble : si un autre élément tombe, il envoi la configuration de ce dernier à un élément de secours qui va reprendre le flambeau, assurant ainsi la haute disponibilité. Enfin, c’est lui qui centralise les demandes des utilisateurs et les transmets au reste de l’architecture.
• Schedulers (ordonnanceurs) : ils ont pour rôle d’ordonnancer les vérifications, et c’est tout : ils ne lancent rien eux mêmes, mais proposent des files d’attentes pour les autres éléments qui vont venir piocher leur travail. Il peut y en avoir autant que l’utilisateur le souhaite.
• Pollers (travailleurs) : Ils sont là pour venir prendre les sondes à lancer auprès des ordonnanceurs, les lancer et retourner les résultats. C’est tout. Plus il y a de pollers, meilleures sont les performances.
• Reactionners (éléments réactifs) : typiquement unique, un tel élément permet de centraliser les notifications et les actions correctrices de tous les ordonnanceurs au même endroit. Plus besoin de demander 20 autorisations SMTP, une seule suffit désormais.
• Broker (récupérateur) : également unique, il récupère toute les données des ordonnanceurs et les fournies à des modules. Ces derniers en font ce qu’ils veulent, à savoir les exporter dans différentes bases comme NDO en MySQL ou Oracle, base Merlin, fichier plat Nagios standard ou encore fichier de performances des services qui recueillera automatiquement les données de tous les ordonnanceurs! Plus besoin d’aller mettre en place des transferts par SCP dans cron. Un module Livestatus est également disponible ainsi qu’un module CouchDB bien qu’aucun client pour ce dernier n’existe pour l’instant

Cette architecture permet une très grande flexibilité et est la meilleure raison de tester Shinken. Elle peut être vue en action dans l’animation suivante :

Tester facilement la version 0.1

Si mettre en place Shinken est simple (il n’a besoin que de deux paquets standard et aucune compilation), ses auteurs ont pensés aux plus feignant d’entre nous : une machine virtuelle toute prête est disponible sur les site officiel. Une fois lancée, il suffit de se connecter avec le compte shinken/shinken et de lancer ./launch_all.sh. C’est tout. Le reste se passe sur l’interface web fournie avec la machine sur http://IPDELAVM/. Elle propose pour l’instant deux interfaces de visualisations : Ninja et Thruk. Ceci permet au passage à ceux qui n’ont pas eu le courage de monter un environnement de test pour ces dernières de voir un peu ce que ça donne.

Les auteurs de Shinken tiennent d’ailleurs à remercier chaleureusement l’équipe de monitoring-fr.org car c’est l’infrastructure de cette dernière qui héberge la machine virtuelle

L’avenir de Shinken

Cette version 0.1 est importante à plus d’un titre pour Shinken. Outre le fait d’être la première véritable version officielle du projet, elle sera également présentée au concours seedcamp qui vient d’être ouvert par l’équipe de Nagios. Il va récompenser les meilleurs nouveaux outils pour Nagios.

Shinken va ainsi (re)demander par ce biais à intégrer officiellement la branche de développement de Nagios. En cas de refus, ce projet continuera seul et nous arriverons à une probable division de la communauté. Mais au moins la concurrence des projets sera bénéfique pour tous les utilisateurs de logiciel de supervision Open Source, et c’est bien ce qui compte.

Résumé du changelog :

• Correction: Chemin en dur dans le statut topcounter
• Correction: Problème dans ACL (drapeau génération n’a pas mis à jour)
• Correction: Problème avec icônes dans le suivi
• Amélioration: Délai pour la génération des ACL
• Amélioration: Numéro de la demande pour la génération des ACL
• Correction: Ajout de verrouillage pour centACL.php
• Amélioration: Amélioration de l’action ACL (horaire de service contraint pas de lien avec le service annexe)
• Amélioration: Optimisation de configuration de SNMPTT
• Amélioration: Ajout d’une « long output » dans l’onglet Monitoring: colonne manquante dans « eventlog export csv »

• CORRECTION: ajout d’une colonne dans l’export au format csv des eventlog
• CORRECTION: Correction sur des problèmes lors de la génération GMT
• CORRECTION: Problèmes lors de changements massifs sur les hôtes
• CORRECTION: lancement de plusieurs commandes externes dû à des clics répétés
• CORRECTION: empêche l’injection SQL pour l’outil de ping
• CORRECTION: Sélection du poller dans la page de Supervision
• AMELIORATION : Purge & Synchro CentStorage
• AMELIORATION : Meilleur Gestion des ACL
• NOUVEAUTE: Affichage des informations des pollers (Etat, latence,…)

Site Officiel – Téléchargement de EON 2.0

Les modifications et nouveautés apportées par la version 2.0 sont les suivantes :

• AJOUT : Cacti Syslog 0.5.2
• AJOUT : Cacti Ntop 0.1
• AJOUT : Cntlm 0.35.1
• AJOUT : Lilac version 1.0.3
• AJOUT : Ndo2fs version 0.2.1
• AJOUT : Nsca version 2.7.2
• AJOUT : Ntop version 3.3
• NOUVEAUTE : Centralisation des logs
• NOUVEAUTE : Gestion de parc GLPI (béta)
• NOUVEAUTE : Ged en backend mysql
• NOUVEAUTE : Import csv multi template
• NOUVEAUTE : Nouveau look interface web
• NOUVEAUTE : Nouveaux logos
• NOUVEAUTE : Recherches avec autocomplete
• NOUVEAUTE : Snmpv3 (tests snmp, interfaces, nagios->cacti)
• NOUVEAUTE : Sonde Réseau
• MAJ : Backupmanager 0.7.8
• MAJ : Cacti version 0.8.7e
• MAJ : Cacti Spine version 0.8.7e
• MAJ : Cacti Plugins version 2.6
• MAJ : Cacti Rrdcleaner version 0.38
• MAJ : Centos version 5.4
• Ged version 1.2.4
• MAJ : Jquery 1.4
• MAJ : Nagios version 3.2.0 core
• MAJ : Nagios Plugins version 1.4.14
• MAJ : Ndoutils version 1.4b9
• MAJ : NagiosBP version 0.94
• MAJ : Nagvis version 1.4.5
• MAJ : Snmptt version 1.3
• MAJ : Weathermap version 0.97

L’équipe de Nagios-fr.org aura très certainement le plaisir de tester cette nouvelle mouture et donnera son avis sur l’évolution de ce produit qui en version 1.2 était déjà très prometteur.