Un petit historique s'impose :

• En 1999, Ethan Galstad créé NetSaint (Futur Nagios).
• En 2002, Suite à des soucis de marque, Ethan dû rebaptiser NetSaint en Nagios.
• En 2006, Ethan lance NDOUtils, projet qui permet d'injecter les données de Nagios est base de données MySQL.
• En 2007, des projets voient le jour en s'appuyant sur la technologies NDOUtils. On voit la naissance de solution s'appuyant sur le cœur de Nagios comme Centreon (passage d'Oreon né en 2003 vers Centreon en 2007), Opsview, Op5Monitor, ...
• En 2007, Naissance de Nagios Enterprise suite a des différences entre NetWays et Ethan Galstad. NetWays ont exploité le nom Nagios en Allemagne. Ethan étant contre ce procédé, il a décidé de fortifier sa politique de Trademarks pour que le projet avance de manière pérenne.
• Suite à ce différent entre la communauté Allemande et le créateur de Nagios, un fork de Nagios du nom d'Icinga est né.
• Ethan lance en 2009 Nagios XI, une version sous licence orienté aux entreprises.
• Nagios Enterprise suit sa politique de respect des trademarks du projet Nagios pour qu'aucun abus soit admis.

Les questions que bons nombres se posent : Y a-t-il un avenir pour Nagios dans la prochaine décennie ? Mais où va la politique de Nagios Enterprise ?

Durant les 10 dernières années, Nagios s'est fait une place dans le monde de la supervision Open Source. Sa notoriété a grandit à un point que des grosses entreprises qui étaient sur des produits propriétaires se laisse charmer par ce succès et la fiabilité de l'outil.

Mais depuis fin 2007, Ethan et sa communauté s'éloigne de plus en plus, le dialogue se fait rare, tendu. Ethan se concentrant sur le développement de Nagios Enterprise, la cadence du développement a ralenti depuis fin 2007 puisque Ethan était jusqu'à ce jour le développeur principal de Nagios. Même si Ton Voon et Andreas Ericsson font un travail remarquable pour faire évoluer le Core, le cercle des développeurs reste fermé et peu de patchs de la communauté se trouve incorporé dans le Core.

Le manque de Roadmap de Nagios, de communication de la part d'Ethan envers sa communauté a fait naître certaines tensions qui ont entrainé la naissance d'un fork comme Icinga et un clash de la communauté Francophone Nagios suite à la parution d'article sur Icinga que Nagios Enterprise désirait voir disparaître.

Le sujet de cet article n'est pas de relancer ce débat mais est plus axé sur l'esprit du libre autour de ce projet.

Suite à ce clash, nous avons remarqué qu'une censure a été imposé par Nagios Enterprise sur la lettre ouverte à Ethan émise dans le ideas.nagios.org. Jean Gabès qui proposait son POC à Ethan pour que Nagios garde son élan des 10 dernières années afin d'améliorer les faiblesses du Core n'a eu aucune réponse.

Dernièrement, Nagios Enterprise a ouvert un concours destiné à tous les développeurs pour émettre leurs idées pour faire évoluer le Core de Nagios. Jean Gabès a proposé Shinken une fois de plus à Nagios Enterprise afin de montrer sa réelle conviction à ne pas lancer une solution de supervision supplémentaire.

Hier, une réponse de "La mère de Nagios" (responsable des ventes Nagios Enterprise) sur Twitter a été plus que clair sur ce sujet : "Pas de Shinken, ni d'Icinga aux Seedcamp". Elle remet aussi en cause le "Nagios WorkShop" en Allemagne ...

Où va mener cette politique de Nagios Enterprise ?

Assistons-nous à la transformation d'un projet Open Source en Open Core(1) ?

La communauté a-t-elle encore son mot à dire ? Peut-on encore parler de communauté ?

(1) : Open Core : Le principe est simple : une version open source, nommée Community, est fournie. Une version Enterprise, privatrice, est également présente et est la seule version supportée par la société éditrice du logiciel . Cette version possède des fonctionnalités bien plus avancées que la Community. Il est dit qu’au bout d’un moment, les avancées de la version Enterprise sont avantageux pour la community.

RSur le même sujet:

1. Thruk : une alternative aux cgi nagios Thruk est une réécriture des cgi Nagios mais en perl et s’appuyant sur livestatus (livestatus est un module de courtage d’évènements  pour Nagios qui permet de se passer des “middlewares” base de données type ndoutils/merlin pour accéder aux données). L’auteur ne s’est pas contenté de juste réécrire les cgi mais à...

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.

RSur le même sujet:

1. Shinken : Nagios Core killler ? Une proposition étonnante a eu lieu sur la mailing list de développement de Nagios. Jean Gabès propose ni plus ni moins que de changer l’implémentation en C du cœur de Nagios par une nouvelle faite en Python qui est plus rapide et plus modulaire. Le...
2. Nouvelle Version 1.1.3 de check_MK Même si il n’y a pas d’annonce officielle sur le site de mathias , check_mk est sorti en version 1.1.3. Pour rappel check_mk est un ensemble constitué de : Un agent de supervision (qui fonctionne sur linux, solaris, aix, windows …) Des plugins de check...
3. Nouvelle version des forums Après le galop d’essai des forums actuels, il a été décidé de créer un espace plus fonctionnel et dédié à ceux-ci. Vous trouverez donc désormais les forums ici et il faut se réenregistrer pour ceux qui l’avaient déjà fait. Désolé pour ce petit inconvénient, vite...
4. check_mk arrive en version 1.1.2 Mathias Kettner nous annonce sur la mailing list Betatesters que la version 1.1.2rc1 de check_mk va bientôt sortir. Pour rappel check_mk est constitué de deux principaux projets : check_mk est un plugin de check nagios (et un agent multiplateforme : windows, linux, aix, solaris …) novateur...

• Navigation par page
• Agrégation de plusieurs "collecteurs" nagios/icinga (pas vraiment du distribué mais de l'agrégation en console unique, ce qui a le mérite de ne pas introduire la complexité de configuration des environnements distribués nagios).
• Moteur de recherche multi critères
• Support des thèmes
• Repliement du tac pour gagner en visibilité sur les tableaux
• Filtrage des "collecteurs" (on peut directement sélectionner le ou les collecteurs dans l'interface)
• Possibilité d'ajuster la fréquence de rafraichissement de l'écran.
• Recherche dans les logs avec inclusion/exclusion de termes (par exemple inclure serveur et exclure serveur_windows).

On perd au passage la "map" mais est ce un mal quand on a nagvis à disposition (qui supporte également livestatus au passage)?. Le système de frames disparaît aussi (mais peut être réactivé pour conserver la compatibilité avec certains addons)
la démo est bluffante en terme de performances 20000 services et 1000 hôtes répartis sur 5 collecteurs.

On aime ou on aime pas "l'ergonomie" et le "design" des cgi nagios, mais pour un parc déjà installé cela peut se révéler une alternative tout a fais crédible. Et le fait de ne pas avoir a installer la console sur les "collecteurs" est également une bonne chose.

Site de thruk : http://www.thruk.org
Demo : http://www.thruk.org/demo.html
Github : http://github.com/sni/Thruk

RSur le même sujet:

1. Où va Nagios ? Le projet Open Source Nagios a dépassé une première décennie et se trouve actuellement sur la pente de la gloire. Ayant une communauté de + de 250000 utilisateurs ainsi que de nombreux développeurs d’addons autour de celui-ci. Nagios est devenue une référence dans le domaine...
2. Sortie de Nagios Core 3.2.1 C’est avec un peu de retard que nous annonçons la sortie de nagios-core dans sa version 3.2.1. Après 7 mois, l’équipe de développement Nagios sortent la version 3.2.1. Elle présente peu de correctif mais certains ne sont pas des moindres. Amélioration de la compilation de...
3. Quand la supervision rencontre la Sécurité Quand la supervision rencontre la sécurité ça nous fait une solution Open Source digne de ce nom à base de : Nagios Prelude Snort Ossec Ce projet a été élaboré en labo par Ludovic VALENTIN dans le cadre d’un stage. La documentation qui en est...
4. Nouvelle Version 1.1.3 de check_MK Même si il n’y a pas d’annonce officielle sur le site de mathias , check_mk est sorti en version 1.1.3. Pour rappel check_mk est un ensemble constitué de : Un agent de supervision (qui fonctionne sur linux, solaris, aix, windows …) Des plugins de check...

Après 7 mois, l'équipe de développement Nagios sortent la version 3.2.1. Elle présente peu de correctif mais certains ne sont pas des moindres. Amélioration de la compilation de Nagios sur Fedora et Solaris . Correction de bugs sur la planification qui s'avérait assez gênant. Je pense que bon nombre d'entre vous les attendaient.

Et une nouvelle fonctionnalité qui pour ma part je trouve réellement intéressante pour l'automatisation de la planification des période de maintenance (downtime) pour tous les services d'un hôte. Avant, on était obligé de lancer une commande externe pour chacun des services, ce qui était assez lourd en soit.

On espère que l'équipe de développement Nagios continue sur cette lancée et nous offre de bonne petites fonctionnalités pour les prochaines moutures.

Au menu des festivités on notera :

Améliorations (traduction libre):

• Apparition d'un lien permettant de programmer la maintenance (downtime) de tous les services d'un hôte (Hendrik Baecker)
• Accélération des CGIs en présence de nombreux commentaires et/ou mise en maintenance dans le fichier status.dat (Jonathan Kamens)
• Patch de new_mini_epn permettant d'éviter que des lignes de commandes soient tronquées (Ray Bengen)

Corrections (traduction libre):

• Correction des erreurs de planification quand l'heure est retardée (correction partielle pour 24x7)
• Correction permettant de compiler sur Fedora Core 3 (bug #0000082)
• Correction permettant de compiler sur Solaris
• Correction sur les tests de connection pour prise en compte du fuseau horaire (bug #0000077 - Allan Clark)
• Nettoyage de autoconf (Allan Clark)
• Correction pour validation CSS de l'attribut padding: X
• Correction sur la documentation re: variables personnalisées non sensibles à la casse (Marc Powell)
• Correction sur les templates de configurations qui utilise des inversions de joker (Tim Wilde)

RSur le même sujet:

1. Nagios Core 3.2.0 Nagios Core 3.2.0 vient juste de sortir pour corriger quelques bugs présents dans les précédentes versions. Mais ce qui est le plus notable avec cette version est le “nouveau” nom de Nagios qui devient Nagios Core. C’est évidemment un nouveau pas de plus vers la...
2. Nagios 3.0.4 La version 3.0.4 de Nagios vient de sortir pour corriger les problèmes présents dans les version 3.0.3 et antérieures. Les corrections suivantes ont été apportées : Terminaison des processus corrigée lorsque le processus parent a été tué (ex: utiliser la commande ‘killall nagios’ alors que...
3. Sortie de Centreon 2.1.6 La nouvelle version de centreon est sortie. Merethis s’est fait discret sur cette release mais en même temps, il ne s’agit que d’une mise à jour mineur. Elle corrige les bugs suivants : CORRECTION: ajout d’une colonne dans l’export au format csv des eventlog CORRECTION:...
4. Shinken : Nagios Core killler ? Une proposition étonnante a eu lieu sur la mailing list de développement de Nagios. Jean Gabès propose ni plus ni moins que de changer l’implémentation en C du cœur de Nagios par une nouvelle faite en Python qui est plus rapide et plus modulaire. Le...
5. Nagios Core Nagios est un logiciel de supervision destiné à vous informer de problèmes éventuels dans votre système d’informations avant que vos clients, utilisateurs ou managers ne le fassent. Il est prévu pour fonctionner sur système d’exploitation Linux mais fonctionne également sans problème sur la plupart des...

• Nagios
• Prelude
• Snort
• Ossec

Ce projet a été élaboré en labo par Ludovic VALENTIN dans le cadre d'un stage. La documentation qui en est ressortie est sublime et nous montre comment monter cette solution de A jusqu'à Z. Superviser votre infrastructure c'est bien, mais bien la protéger et être au courant lorsque vos barrières sont percés, ce sujet est rarement évoqué sur la toile. L'équipe Nagios-fr.org a décidé de remettre en forme le travail de Ludovic sur le Wiki pour en faire profiter tous les adeptes de la sécurité. Une section du Wiki est désormais consacrée à ce domaine.

Encore une fois un grand merci à ce contributeur Ludovic VALENTIN pour son travail. En espérant que ce dossier pourra vous aider pour boucher les failles de votre Infrastructure.

RSur le même sujet:

1. Standards de la supervision Le monde de la supervision et du management des infrastructures en général possèdent ses normes et standards, pour la plupart émergeants, dont sont présentés ici les plus significatifs. Ces standards sont pour la plupart gérés par la DMTF Standards de la supervision IPMI — Intelligent...
2. wiki.nagios-fr.org — Installation Nagios 3.x sur CentOS 5.3 A ce jour, une nouvelle page de wiki est disponible expliquant comment installer un Nagios 3.x sur une CentOS. Vous trouverez un bas de cette page les pièges que j’ai rencontré lors que l’installation de celui-ci alors méfiance. Vous pouvez y accéder via l’URL suivante...
3. Uptime : Mesure universelle ? Il est admis que la mesure de base qui compte en supervision est le Uptime (temps de disponibilité d’un service et Nagios est prévu pour ce genre de réponse. Mais est-il intéressant, voir utile de rapporter à votre direction informatique sur ce type d’indicateur ?...
4. Communauté francophone de la supervision La Communauté Nagios Francophone est née de la démarche individuelle d’Olivier Jan qui a publié en octobre 2007 ces notes de recherches autour de Nagios et la supervision Open Source en général. Rejoint en janvier 2009 par Romuald Fronteau pour la création et l’administration des...
5. Supervision 2010 : Les forces en présence Il m’a paru intéressant avec l’année 2009 que nous venons de vivre en supervision Open Source de faire le point sur les forces en présences en début de cette année 2010. Côté Nagios, 2010 pourrait voir une redistribution des cartes entre le Nagios Core et...

Installation de Nagios 3.x sur CentOS 5.3

ou directement en cliquant sur le menu Wiki en haut de l'écran.

RSur le même sujet:

1. wiki.nagios-fr.org — Dossier Centreon Surfant un peu sur le web .… oui beaucoup je l’accorde. J’ai vu des plaintes de certains internautes vis-à-vis de Merethis et de la documentation lié à Centreon. L’idée m’est venu de faire un gros dossier Centreon comprenant 3 parties : Installation de Centreon 2.1...
2. Wiki ...
3. Quand la supervision rencontre la Sécurité Quand la supervision rencontre la sécurité ça nous fait une solution Open Source digne de ce nom à base de : Nagios Prelude Snort Ossec Ce projet a été élaboré en labo par Ludovic VALENTIN dans le cadre d’un stage. La documentation qui en est...
4. Thruk : une alternative aux cgi nagios Thruk est une réécriture des cgi Nagios mais en perl et s’appuyant sur livestatus (livestatus est un module de courtage d’évènements  pour Nagios qui permet de se passer des “middlewares” base de données type ndoutils/merlin pour accéder aux données). L’auteur ne s’est pas contenté de juste réécrire les cgi mais à...
5. Supervisez vos logs de manière centralisée 8pussy (Octopussy) est une application dédiée au traitement des journaux capable d’analyser, d’alerter et de rendre des statistiques sur les événements qui y sont contenus. 8Pussy est capable d’analyser, entre autres, les journaux des services suivants : Bind, Cisco Router, Cisco Switch, DenyAll Reverse Proxy,...