Sortie de Nagios 2.0

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
9
fév.
2006
Technologie
Après plus d'un an de développement la première version de la série 2.x de Nagios est sortie : la 2.0.

Nagios est un moniteur de supervision, successeur de NetSaint. Il permet une supervision de serveurs, équipement réseaux et des services.

Le principe de Nagios est simple :
* un ordonnanceur gérant les actions
* une IHM légère via une interface web
* les sondes qui sont chargées d'effectuer les vérifications

Nagios est sous licence GPL v2.

Il est disponible sous forme de packages RPM pour Fedora et RedHat ou via l'archive des sources à recompiler.

NdM : Merci à KaTeznik pour avoir également proposé l'information. Parmi les concurrents Open-Source de Nagios on citera de manière non-exhaustive :
* cacti
* opennms
* zabbix

Un résumé des nouveautés de la série 2.X :
* Mise à jour de la documentation
* Utilisation d'automake version 1.9
* Suppression de la limitation pour les objets vars/vals
* Correction des segfaults dans la file d'attente synchronisée des événements.
* Correction de l'initialisation des scripts Perl embarqués et changements mineurs
* Correction des duplications potentielles des entrées de bug dans les groupes
(host/service/contact)
* Correction dans la résolution des templates des variables contactgroups dans la définition des contacts
* Correction du bug sur les commentaires qui n'expirent pas
* Correction du bug sur les objets non enregistrés dans wildcard/regex templates
* Ajout d'une option configuration pour désactiver l'utilisation de nanosleep() dans la file d'attente des événements.
* Amélioration des vérifications circulaires des chemins/dépendances pour éviter les segfaults
* Changement de la licence pour la GPL v2
* Correction du format des dates non US dans les commandes CGI
* Ajout de vérifications durant l'écriture de données pour des partitions pleines
* Correction de l'ordre des fichiers includes dans config.h pour nettoyer la compilation pour OpenBSD 3.6
* La recherche des noms d'hôtes dans l'interface web est maintenant sensible à la casse.
* Correction du bug dans les temps reportés par l'utilitaire nagiostats
* Nagios change maintenant ses privilèges avant de lire les fichiers de configurations (et sort s'il ne peut le faire)
* Correction du bug qui faisait que de mauvais fichiers étaient parsés par récursion lors du parcours du répertoire de configuration
* Amélioration du script d'init lors de l'arrêt de Nagios
* Amélioration de mini EPN
* Correction des messages d'erreurs dans les log lors du démarrage
* Ajout des macros $HOSTCHECKTYPE$, $SERVICECHECKTYPE$ et $PROCESSSTARTTIME$
* Correction des bugs dans la macro $LASTHOSTCHECK$
* Mise à jour du module helloworld NEB pour montrer comment enregistrer des routines de rappel
* Hôte par défaut pour les cas où ne sont pas spécifiés d'hôtes ou d'alias
* Ajout de commandes externes pour ajuster les numéros de notification des hotes et des services
* Changement du script d'init
* Ajout des options de sorties MRTG dans l'utilistaire nagiostats
* Changement dans les commandes de la bibliothèque dans les scripts de test de GD
* Augmentation du buffer de commande de 4K à 32K
* Suppression des appels (un)setenv() pour les systèmes qui ne les supportent pas
* Ajout du groupe service
* ..

Aller plus loin

  • # Cacti ?

    Posté par  . Évalué à 10.

    Autant opennms ou zabbix sont des concurrents de nagios , autant cacti ne l'est pas , il ne fait que grapher ( et c'est à mon avis un des meilleurs dans son domaine ) , il ne fait aucune remontée d alerte, aucun monitoring de service, dans ce cas il faut le coupler avec un soft comme monit ou mon.
  • # PHP

    Posté par  . Évalué à 10.

    J'ai oublié de souligner le projet d'interface web pour nagios en PHP : http://nagios-php.sourceforge.net/
  • # Hobbit Monitor

    Posté par  (site web personnel) . Évalué à 10.

    On est en train de déployer Hobbit chez mon client, sur un parc hétérogène de 150 machines HP-UX, AIX, Solaris, Linux (Red Hat AS 2.1 et 3).

    http://hobbitmon.sourceforge.net/
    • [^] # Re: Hobbit Monitor

      Posté par  (site web personnel) . Évalué à 10.

      J'utilise Hobbit (en remplacement depuis Big Brother) depuis novembre dernier, pour superviser 1400 équipements (~ 1000 serveurs Unix, Windows, AS/400, MVS et ~ 400 routeurs, switches, AP, "boites noires").

      Le tout représente 2200 tests réseau (ping, HTTP, etc.) et 9000 ressources (CPU, disques, etc.)
      Ca tourne sur un bi Xeon 3.2 GHz dont la load average ne dépasse pas 0.8, et le temps de génération des 300 pages web est d'une demi seconde.

      J'utilisais déjà bbgen par-dessus Big Brother, mais je conseille vraiment de migrer vers Hobbit !
      • [^] # Re: Hobbit Monitor

        Posté par  (site web personnel) . Évalué à 6.

        Et la cerise, monitoring avance de LDAP et des certificats avec verification de leur expiration (LDAPs). Une tuerie.

        Steph
        • [^] # Re: Hobbit Monitor

          Posté par  (site web personnel) . Évalué à 6.

          Idem pour HTTPS, les admins sont bien contents d'être prévenus x jours à l'avance que leur certificats vont expirer...

          Hobbit 4.2 étant "sur le point" de sortir, j'essaierai de m'y coller pour proposer une dépêche.
      • [^] # Re: Hobbit Monitor

        Posté par  . Évalué à 3.

        Pour l'instant, j'utilise encore Big brother mais je regarde avec intérêt Hobbit.

        L'esprit de BB est là avec en plus, cerise sur le gâteau, des graphiques.

        Par contre, côté client cela me paraît pas encore assez limité car surtout orienté unix/intel (linus, netbsd) ou, si j'ai bien compris, il faut utiliser le client original de BB qui n'est pas open source.

        Comme je gére principalement des serveurs AIX (5.1, 4.3 et 4.2) je ne suis pas certain d'avoir les + de hobbit (les graph notamment).

        autre point qui me paraît génant aussi, c'est qu'il n'y a pas de client windows (sauf celui de BB qui est propriétaire) et j'ai quelques machines en windows 2k server et 2003.

        en plus j'utilise certaines extensions que l'on trouve sur deadcat comme l'extension oracle ou des extensions spécifiques AIX (lvm, errpt, ...). A priori, elles pourraient fonctionner avec hobbit mais ce n'est pas certain.

        je n'ai malheureusement pas le temps de tester.

        la question est de savoir si actuellement c'est vraiment intéressant de migrer vers hobbit et avec quelle charge de travail pour l'adaptation. La documentation n'est pas très claire la dessus.

        Si la charge d'adaptation est trop lourde, l'autre solution est de prendre carrément autre chose comme Nagios, Oeron ou Zabbix (quid de Oracle ?) .

        à suivre donc ;o)
        • [^] # Re: Hobbit Monitor

          Posté par  (site web personnel) . Évalué à 4.

          Par contre, côté client cela me paraît pas encore assez limité car surtout orienté unix/intel (linus, netbsd) ou, si j'ai bien compris, il faut utiliser le client original de BB qui n'est pas open source.

          En fait le client Hobbit, depuis la version 4.1, fonctionne sous AIX, Linux, HP-UX, Solaris, Tru64, Darwin et *BSD.

          Pour l'instant les seuils se paramètrent de façon centralisée sur le serveur Hobbit; la version 4.2 permettra de gérer les seuils sur les clients.

          en plus j'utilise certaines extensions que l'on trouve sur deadcat comme l'extension oracle ou des extensions spécifiques AIX (lvm, errpt, ...). A priori, elles pourraient fonctionner avec hobbit mais ce n'est pas certain.

          Quelques rares scripts externes demandes à être modifiés pour fonctionner (ceux qui tournent sur le serveur Hobbit, basés sur SNMP par exemple), mais les scripts comme Oracle fonctionnent sans rien modifier.

          je n'ai malheureusement pas le temps de tester.

          la question est de savoir si actuellement c'est vraiment intéressant de migrer vers hobbit et avec quelle charge de travail pour l'adaptation. La documentation n'est pas très claire la dessus.

          Si la charge d'adaptation est trop lourde, l'autre solution est de prendre carrément autre chose comme Nagios, Oeron ou Zabbix (quid de Oracle ?) .

          Une doc sur la migration BB -> Hobbit est disponible ici : http://www.hswn.dk/hobbit/help/bb-to-hobbit.html

          Quand j'ai migré, je me suis contenté :
          - d'arrêter le démon bbd
          - démarrer le démon hobbitd
          - attendre que la carte se reconstruise ;-)

          Les logs BB sont compatibles avec Hobbit, tu conserves tout y compris l'historique.

          Concernant l'intérêt d'une telle migration, j'ai divisé la load average de mon serveur par ~ 10, donc oui ça vaut le coup :-)
          • [^] # Re: Hobbit Monitor

            Posté par  . Évalué à 2.

            Ok, merci pour ces informations intéressantes.

            J'attendrai donc la sortie de la 4.2 pour pouvoir tester avant d'envisager de mettre en production.

            ayant moins d'équipement, je n'ai pas de problème de charge sur le serveur BB (un vieux proliant ml350 PIII 1Ghz avec 512mo).

            par contre comme je prévois de surveiller également mes équipements réseaux (avec les graphes en plus), cela risque d'être intéressant d'évoluer vers hobbit.

            Côté SNMP, est-il prévu quelque chose en natif dans les prochaines version ?
        • [^] # Re: Hobbit Monitor

          Posté par  (site web personnel) . Évalué à 2.

          A priori, la migration de Big Brother vers Hobbit est transparente : mêmes fichiers de conf, même fonctionnement; etc.

          Ici, on a Hobbit sur les mêmes version d'AIX que toi : no problem.

          En plus on a du Linux bien sûr, mais aussi et surtout du HP-UX et du Solaris, mais je me répète...
          • [^] # Re: Hobbit Monitor

            Posté par  . Évalué à 2.

            Purée en env hétérogène Unix/Linux, : ça embauche par là ??
            • [^] # Re: Hobbit Monitor

              Posté par  . Évalué à 2.

              J'ai aussi du netware 6.5 sur mon parc ;o)

              sinon on embauche (sur Béthune) un administrateur (niveau bac +2) serveur et DBA ayant les compétences d'administration AIX, Linux (SLES 9), DBA Oracle et si possible Netware 6.5 / Windows server (2k et 2003) / connaissances réseaux

              bon désolé pour la pub (n'hésitez pas à me modérer si nécessaire)
  • # alertes par push Jabber

    Posté par  (site web personnel) . Évalué à 7.

    La plupart de ces outils n'ont pas de client desktop lourds, ils sont tous en clients web, donc il faut recharger les pages en permanence, à moins d'utiliser l'extension Firefox reload-every.

    Donc pas de remontées d'altertes interactives en push... sauf par e-mail, mais c'est un peu léger quand on veut de l'immédiateté pour un maximum de réactivité...

    Le top est d'installer un serveur Jabber en interne, le serveur de supervision/monitoring étant connecté au réseau Jabber interne en tant que client Jabber, il peut envoyer des alertes à d'autres utilisateurs humains ou des chatrooms, voire des commandes...

    Voir Neutron et JabberWatcher par exemple :
    http://ejabberd.jabber.ru/neutron
    http://jabberwatcher.sourceforge.net/
    • [^] # Re: alertes par push Jabber

      Posté par  . Évalué à 4.

      Le top est d'installer un serveur Jabber en interne, le serveur de supervision/monitoring étant connecté au réseau Jabber interne en tant que client Jabber, il peut envoyer des alertes à d'autres utilisateurs humains ou des chatrooms, voire des commandes...


      Ah pas mal c'est super intéressant comme idée. J'ai gratté un peu et je suis tombé sur http://xavier.dusart.free.fr/nagios/jabber.html
      • [^] # Re: alertes par push Jabber

        Posté par  . Évalué à 10.

        Salut,

        J'utilise aussi Nagios pour monitorer mes serveurs / reseaux depuis plusieurs années. Si ca vous interesse, j'ai une checkcommand en perl qui envoie les alarmes à un client jabber.


        #!/usr/bin/perl -w

        use strict;
        use Net::Jabber qw(Client) ;
        use Net::Jabber qw(Message) ;
        use Net::Jabber qw(Protocol) ;
        use Net::Jabber qw(Presence) ;

        use constant RECIPIENT => $ARGV[0];
        use constant SERVER => 'jabber.org';
        use constant PORT => 5222;
        use constant USER => 'xxxxx';
        use constant PASSWORD => 'xxxxx';
        use constant RESOURCE => 'perl script';
        use constant MAXWAIT => 10 ;

        use vars qw/%presence/;

        my %users;
        my $connection = Net::Jabber::Client->new();

        ########################################
        #
        # Affiche la présence en ligne
        #
        ########################################
        sub handle_presence
        {
        my ($jid, $presence) = @_;
        my $fromJID = $presence->GetFrom("jid");
        my $uid = $fromJID->GetUserID();
        if ($presence->GetType() eq "unavailable")
        {
        delete($users{$uid});
        }
        else
        {
        $users{$uid} = 1;
        }
        $presence{$jid} = $presence->GetShow() || 'normal';
        }

        my $len = scalar @ARGV;
        my @field=split(/,/,$ARGV[0]);

        if ($len ne 2)
        {
        die "Usage [jabberid] [message]\n";
        }
        $ENV{https_proxy}="http://xxxxxx:8080";
        $ENV{http_proxy}="http://xxxxxx:8080";

        $connection->SetCallBacks( "presence" => \&handle_presence );

        $connection->Connect( "hostname" => SERVER,"port" => PORT,"connectiontype" => "http") or die "Cannot connect ($!)\n";

        my @result = $connection->AuthSend( "username" => USER,"password" => PASSWORD,"resource" => RESOURCE );
        $connection->PresenceSend();

        if ($result[0] ne "ok")
        {
        die "Ident/Auth with server failed: $result[0] - $result[1]\n";
        }


        $connection->Process(2);
        sleep(3);

        foreach ( @field )
        {
        my($uid) = ($_ =~ m/(.*)\@.*/);
        if(exists $users{$uid})
        {
        my $message = Net::Jabber::Message->new();
        $ARGV[1]=~s/\\n/\n/g;
        $message->SetMessage( "to" => $_, "type" => "chat", "body" => "$ARGV[1]");
        $connection->Send($message);
        sleep(MAXWAIT);
        }
        }
        $connection->Disconnect();
        exit;


        Il s'utilise en donnant les jabberid séparés par des virgules ainsi que le message. C'est un peu brut, à vous de l'améliorer...
        • [^] # Re: alertes par push Jabber

          Posté par  . Évalué à 2.

          C'est parfaitement HS mais pourquoi les sleep ??
          • [^] # Re: alertes par push Jabber

            Posté par  . Évalué à 2.

            Bonne question, je ne me souviens pas pourquoi j'avais fait ça.

            Mais je devais bien avoir une raison à l'époque.

            Je pense de toute façon que je n'utilise pas très bien le module jabber mais je n'ai pas trop le temps de m'y replonger... et puis ca marche ;-)
  • # Support SQL

    Posté par  (site web personnel) . Évalué à 6.

    Le support SQL original a été enlevé mais il existe déjà un autre support pour Nagios 2.x. grâce au projet Nagios-DB[1].

    [1]: http://sourceforge.net/projects/nagios-db/
    • [^] # Re: Support SQL

      Posté par  . Évalué à 6.

      J'ai testé le support nagios-db. Il faut encore patcher les fonctions de callback car le projet ne semble plus très maintenu. De plus le code est plein de lourdeurs (mais je travaille activement à publier des patchs dés que j'aurais une version propre qui peut marcher en production)
    • [^] # Re: Support SQL

      Posté par  . Évalué à 1.

      Pour nagios 2, mieux prendre NDOutil... developpé par Ethan.
  • # Typo

    Posté par  . Évalué à 3.

    s/sensitive/sensible/
  • # What's new !

    Posté par  (site web personnel) . Évalué à 4.

    Le lien vers le Changelog est intéressant mais n'est pas capital pour savoir ce qui a *vraiment* changé entre les versions 1.x et cette nouvelle mouture. Le lien suivant donne un meilleur état des lieux :

    http://nagios.sourceforge.net/docs/2_0/whatsnew.html
  • # Pour une supervision professionnelle : Nagios + Oreon

    Posté par  . Évalué à 6.

    Bien sur cet avis n'engage que moi (enfin pas tout à fait)...

    Oreon (http://www.oreon-project.org/) est un projet d'interface pour nagios, et de mon point de vue, la solution Nagios/Oreon est la plus aboutie du monde OpenSource.

    Cette solution est celle que je suis en train de mettre en place dans ma société et qui vise à être déployée comme solution de monitoring pour l'ensemble de notre groupe à travers le monde (un grand groupe industriel dont je prefere ne pas citer le nom pour des raisons de confidentialité).

    Pour ceux qui connaissent Oreon et qui suivent son évolution, vous verrez arriver dans les prochains mois une version apportant toutes les modifications développées à notre initiative et réalisées par l'équipe projet d'Oreon (dont une partie des membres fondateurs travaillent avec moi en ce moment et que je salue au passage). En effet, tous les developpements que nous avons commandés (pour plus plus de 50 000¤, soit plus de 6 mois*hommes) sont directement reversés à la communauté.

    Parmis les nouveautés :
    - ergonomie encore amméliorée
    - gestion de "MetaServices" (services aggrégeant les données d'autres services)
    - historisation des données (à la Zabbix)
    - gestion de la qualité de service (d'un point de vue Technique ou Business)
    - frontend de supervision en JAVA/WebStart avec gestion de maps à n-niveaux
    - connexion possible sur les agents Zabbix déployés
    - plein d'autres choses que j'oublie
    • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

      Posté par  . Évalué à 1.

      Hello,

      juste une petite question : pourquoi le support de nagios 2 tarde ? les betas sont disponibles depuis de nombreux mois, il aurait été cool de bosser dessus, non ?
      • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

        Posté par  . Évalué à 3.

        Bien que ne faisant pas parti des équipes de développement, je vais donner mon avis sur la question.

        Le support tarde pour deux raisons
        - Tout d'abord, les support pour Nagios 2 est en developpement depuis longtemps, mais jugé non utilisable en production.
        - Oreon est utilisé par des sociétés (parmis lesquelles des grands comptes dont ma société fait parti) et à ce titre, dans les developpements réalisés depuis un an, l'accent à été mis sur les fonctionnalités "professionnelles".

        Je tiens à préciser que je monopolise une bonne partie de l'équipe de developpement depuis octobre 2005 et que les developpements qu'ils réalisent sont (d'un point de vue professionnel) plus important que la compatibilité Nagios 2 (bien que ce soit prévue pour le mois de mai.

        Bien sur, tous les developpements réalisé actuellement seront compatible nagios 1.x et nagios 2
    • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

      Posté par  . Évalué à 3.

      Une autre petite question :p
      Est-ce qu'Oreon peut-être installé sur une autre machine que celle qui fait tourner Nagios?
      Actuellement, nous avons un parc trop important pour faire tourner autre chose que Nagios et faire le rendu dans un temps raisonnable sur une machine.
      Une solution type Nagios sur une machine et une autre machine pour Cacti et NagiosGraph (montage NFS des perfdata Nagios) semble la plus performante.
      En gros, Oreon n'est-il pas une usine à gaz? /o\
      • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

        Posté par  . Évalué à 3.

        Oui, ce que vous décrivez est dors et déjà possible, mais encore un peu contraignant.

        Il est possible pour un serveur nagios de recupérer passivement les resultats des checks effectués par un autre serveur nagios.

        En exploitant cette fonctionnalité, il est possible d'avoir un (ou plusieurs) serveur executant les tests, et un autre avec Oreon "aggregeant" ces données pour les grapher.

        Dans le futur proche (voir la roadmap : http://www.oreon-project.org/Oreon-RoadMap-fr.html ) Centreon permettra de faire cela :

        Centreon et une nouvelle architecture d'Oreon permettant à celui ci de generer des configurations pour des serveurs nagios distants. En d'autres termes, une console unique permettra d'administrer des serveurs nagios répartis et permettra ainsi de deporter des tests. Il y aura donc bien séparation entre les nagios effectuant les checks et Oreon gérant les configurations et le reporting.
    • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

      Posté par  . Évalué à 2.

      Cette solution est celle que je suis en train de mettre en place dans ma société et qui vise à être déployée comme solution de monitoring pour l'ensemble de notre groupe à travers le monde (un grand groupe industriel dont je préfère ne pas citer le nom pour des raisons de confidentialité).


      Si tu veux pas donner le nom de ta boite, alors évite de mettre ton prénom et nom en clair comme non d'utilisateur...
      30 seconds de Googling suffisent a trouver que tu bosse pour Lafarge

      http://h41087.www4.hp.com/solutions/administrations/hpeduc/l(...)

      PS: Apparemment c'est pas secret pour HP le fait que tu travailles la bas.

      Un autre lien pour la route avec ta signature...

      http://archives.linuxfromscratch.org/mail-archives/lfs-tradu(...)


      En tout, je suis de tout coeur avec toi, car Nagios mérite bien le support de grand groupe comme le tien, je l'utilise dans ma boite mais malheureusement a part l'amélioration de l'interface WEB (Nagios Nuvola theme), j'ai pas trop le temps de contribuer a ce superbe projet et surtout un super Life Saver.
      • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

        Posté par  . Évalué à 2.

        Je ne cherche pas à cacher pour quel société je travaille, mais n'étant pas représentant officiel de cette société, je ne peux pas l'engager dans mes propos.

        Nous sommes ici sur un site "publique" alors que dans le cas d'HP, un partenariat existe leur permettant de me nommer.

        Les contrats sont ainsi faits...

        Mais le fait est que l'OpenSource m'a beaucoup apporté et que je le lui rends dès que possible, avec les moyens qui sont les miens.
    • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

      Posté par  (site web personnel) . Évalué à 3.

      - gestion de "MetaServices" (services aggrégeant les données d'autres services)

      Peux-tu être plus précis ?

      Ce qui me gêne davantage dans Oreon, pour l'avoir déployé chez de nombreux clients, ce n'est certainement pas le support de Nagios 2.
      Encore qu'on peut se demander s'il le supporte car il pose la question de la version de Nagios dès l'installation.
      Bien que de récentes réponses à des bogues que j'ai ouvert sur leur flyspray semblent avoir trouvé une issue, je n'ai pas encore vu leur application dans le cvs actuel. Et c'est ce manque de support presque complet de Nagios 1.x que je trouve gênant. Bien sûr, Oreon remplit très bien son rôle d'interface de configuration, évitant à des profanes d'éditer les fichiers de configuration de Nagios. Je regrette surtout que le développement soit trop proche de ces fichiers de configuration.
      Sans doute aurait-il été plus pertinent d'en faire abstraction et de penser à faciliter la saisie des divers objets de la configuration, comme par exemple, ne pas dissocier les hôtes et les extensions d'hôtes (de même pour les services).
      Et sur ce plan-là, Oreon ne facilite guère cette saisie. Il y a bien la duplication des hôtes, fonctionnalité qu'on avait demandé et merci beaucoup d'ailleurs. Mais je regrette certaines fonctionnalités qu'offre Nagios 1.x et que ne permette plus Oreon ! Surtout quand il s'agit de fonctionnalités qui ne sont pas insignifiantes, comme associer un service à un groupe d'hôtes ou créer un modèle à partir d'un autre modèle (quand on peut créer un modèle pour un objet, car tous les objets ne peuvent pas avoir de modèles alors que Nagios offre ces fonctionnalités...). Il s'agit là pourtant de fonctionnalités qui permettent justement de réduire, de simplifier la saisie... En fait, pour être honnête, je me suis souvent demandé si les développeurs d'Oreon connaissaient bien Nagios.
      Et j'ai bien d'autres idées à développer à ce sujet, comme l'intégration de SNMPtt pour gérer les traps ou un meilleur support des options des plugins pour éviter que les profanes ne soient rebutés par cette phase de configuration.
      Maintenant, je dois avouer que leur produit s'améliore et que l'équipe est ouverte aux suggestions et j'admet que ce n'est pas facile de développer une telle application. Les critiques sont faciles, l'art est difficile, comme on dit.

      Donc, le support de Nagios 2.0 n'est pas la priorité pour moi, d'autant que pas mal de fonctionnalités changent, de nouvelles apparaissent et qu'il faudrait déjà valider cette version avant de pouvoir la déployer. Non, ce qui compte, c'est qu'Oreon supporte davantage et correctement Nagios 1.x, déjà, car ça profitera tout naturellement à Nagios 2.x.
      • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

        Posté par  . Évalué à 2.

        Bonjour,

        Connaissant une partie de l'équipe de développement, je peux te rassurer sur un point : ils connaissent bien Nagios. Cependant, à son origine, Oreon visait à simplifier la configuration de Nagios pour des non-initiés, et des compromis ont du être fait.

        La version actuellement en developpement revient sur bon nombre de limitations et s'en affranchi. Ainsi, les templates de templates deviennent possible, il en est de même du rattachement de services à des hostgroups.

        Concernant tes idées d'améliorations, je t'invite à les partager avec eux par le biais de leur forum. Il sont effectivement très ouverts.

        Concernant les précisions que tu me demande sur les MetaServices, voici plus d'infos :
        Actuellement, s'il est aisé de créer un service récupérant le nombre de users connectés sur une serveur (web par exemple), et qu'il est aisé d'avoir ce même service créé pour chaque serveur d'une ferme de serveur, il est beaucoup moins facile de recuppérer le nbre total d'utilisateurs de la ferme de serveur. Cette opération d'aggrégation est justement réalisée dans un MetaService.
        Le principe est relativement simple : on selectionne une liste de service (soit explicitement, soit via une expression reguliere) et on choisi l'opérateur d'aggrégation (Min, Max, Somme, Moyenne).
        Le service ainsi créé a toutes les propriétés d'un service car du point de vu de Nagios c'en est un. Il est donc possible d'alerter sur des valeurs limites...

        Une autre fonctionnalité est la gestion de la qualité de service. Elle s'inspire de la notion d "IT Services" de Zabbix:
        L'idée est de regrouper des services entre eux (dans ce que l'on appelle une Oreon Service Level - OSL) et de calculer un niveau de disponnibilité basé sur leurs états (si tout est OK : 100%, si tout est CRITICAL : 0%, et entre les deux un algo basé sur des pondération calcul un niveau intermédiaire).
        Bien sur, on peux regrouper des OSL entre elles et ainsi passer d'un qualité de service technique (mes serveurs web et mes bases de données sont OK) à une qualité de service Metier (ma gestion commerciale est OK, ma comptabilité aussi...).

        Si tout cela t'interesse, patient encore 2 ou 3 mois et ce devrait être bon (ce sera en production chez moi dans 1 mois à peine)...
        • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

          Posté par  (site web personnel) . Évalué à 2.

          La version actuellement en developpement revient sur bon nombre de limitations et s'en affranchi. Ainsi, les templates de templates deviennent possible, il en est de même du rattachement de services à des hostgroups.

          Comme je le disais, j'ai vu les confirmations de mes bogues mais pas encore dans le cvs. J'attends donc ces modifications avec impatience pour pouvoir confirmer les corrections apportées.

          Concernant tes idées d'améliorations, je t'invite à les partager avec eux par le biais de leur forum. Il sont effectivement très ouverts.

          Je ne manque jamais une occasion de partager mes idées avec eux, juste le temps de formuler mes requêtes. ;-)

          En tout cas, merci pour toutes tes précisions.
      • [^] # Re: Pour une supervision professionnelle : Nagios + Oreon

        Posté par  . Évalué à 2.

        L'association de services a des hostgroups est bientot dispo. Elle sera dans la 1.3. Pour plus d'info reporte toi au bugtracker et rentre tes feature requests. C'est plus simple.

        Et le mieux c'est de dire ce qui ne va pas sur le forum ou direct par mail. C'est plus simple pour nous que de devoir lire tous les sites web communautaires ;) Même si ce n'est que des remarques toutes bêtes sur la navigation et l'accès aux informations. Et ca fera avancer encore plus vite le schmilblic en plus :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.