Cacti ?

• [^]Re: Cacti ?

  Posté par yoho () le 09/02/2006 à 10:21. (lien). Évalué à 5.

  Cacti = ""concurrent"" de Mrtg

  • [^]Re: Cacti ?

    Posté par tuiu pol (Jabber id, ) le 09/02/2006 à 10:29. (lien). Évalué à 5.

    Pour moi Cacti est un bon frontend aux rrdtools, donc l'un sous-entendait l'autre..

    • [^]Re: Cacti ?

      Posté par Raphaël SurcouF (Jabber id, page perso, ) le 09/02/2006 à 11:05. (lien). Évalué à 4.

      Oui mais on ne peut pas parler exactement de concurrence puisqu'ils sont complémentaires.

• [^]Re: Cacti ?

  Posté par Frédéric Mangeant (page perso, ) le 09/02/2006 à 11:05. (lien). Évalué à 10.

  Cacti peut faire de la remontée d'alarme avec le plugin THold ("Thresholding/Alerting module") : http://forums.cacti.net/viewtopic.php?t=6508
  
  Je ne sais pas trop ce que vaut ce plugin, utilisant Hobbit (ré-écriture de Big Brother sous licence GPL) pour superviser ~ 1400 équipements.
  
  Par contre, un autre plugin pour Cacti peut intéresser les utilisateurs de Nagios : NPC ("Nagios Plugin for Cacti") : http://forums.cacti.net/viewtopic.php?t=10327
  Il permet de visualiser dans Cacti l'état d'un serveur supervisé par Nagios.

  --
  "Join the Navy; sail to far-off exotic lands, meet exciting interesting people, and kill them."

PHP

• [^]Re: PHP

  Posté par Christophe Suire () le 09/02/2006 à 13:25. (lien). Évalué à 7.

  Il y a aussi Fruity.
  http://fruity.sourceforge.net/

• [^]Re: PHP

  Posté par -=[ Benoit Plessis ]=- (page perso, ) le 09/02/2006 à 15:32. (lien). Évalué à 4.

  Et oreon

  --
  Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)

  • [^]Re: PHP

    Posté par Raphaël SurcouF (Jabber id, page perso, ) le 10/02/2006 à 16:04. (lien). Évalué à 3.

    dont l'url est :
    http://www.oreon-project.org/

Hobbit Monitor

• [^]Re: Hobbit Monitor

  Posté par Frédéric Mangeant (page perso, ) le 09/02/2006 à 13:48. (lien). É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 !

  --
  "Join the Navy; sail to far-off exotic lands, meet exciting interesting people, and kill them."

  • [^]Re: Hobbit Monitor

    Posté par FRLinux (page perso, ) le 09/02/2006 à 20:03. (lien). É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 Frédéric Mangeant (page perso, ) le 10/02/2006 à 10:23. (lien). É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.

      --
      "Join the Navy; sail to far-off exotic lands, meet exciting interesting people, and kill them."

      • [^]Re: Hobbit Monitor

        Posté par tuiu pol (Jabber id, ) le 10/02/2006 à 16:51. (lien). Évalué à 2.

        Oh tiens la bonne idéee :)

  • [^]Re: Hobbit Monitor

    Posté par Olivier Boyaval (page perso, ) le 10/02/2006 à 12:59. (lien). É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 Frédéric Mangeant (page perso, ) le 10/02/2006 à 13:33. (lien). É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 :-)

      --
      "Join the Navy; sail to far-off exotic lands, meet exciting interesting people, and kill them."

      • [^]Re: Hobbit Monitor

        Posté par Olivier Boyaval (page perso, ) le 10/02/2006 à 20:36. (lien). É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 Nÿco (Jabber id, page perso, ) le 10/02/2006 à 13:35. (lien). É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...

      --
      Jabber ID : xmpp:Nyco@jabber.fr

      • [^]Re: Hobbit Monitor

        Posté par tuiu pol (Jabber id, ) le 10/02/2006 à 16:57. (lien). Évalué à 2.

        Purée en env hétérogène Unix/Linux, : ça embauche par là ??

        • [^]Re: Hobbit Monitor

          Posté par Olivier Boyaval (page perso, ) le 10/02/2006 à 20:58. (lien). É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

• [^]Re: alertes par push Jabber

  Posté par tuiu pol (Jabber id, ) le 09/02/2006 à 14:14. (lien). É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 DOUCET Pierre (Jabber id, page perso, ) le 09/02/2006 à 20:59. (lien). É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 tuiu pol (Jabber id, ) le 10/02/2006 à 00:47. (lien). Évalué à 2.

      C'est parfaitement HS mais pourquoi les sleep ??

      • [^]Re: alertes par push Jabber

        Posté par DOUCET Pierre (Jabber id, page perso, ) le 10/02/2006 à 10:08. (lien). É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

• [^]Re: Support SQL

  Posté par Vincent LE LIGEOUR () le 09/02/2006 à 15:41. (lien). É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 julio234 () le 13/02/2006 à 09:54. (lien). Évalué à 1.

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

  • [^]Re: Support SQL

    Posté par Raphaël SurcouF (Jabber id, page perso, ) le 13/02/2006 à 13:43. (lien). Évalué à 2.

    Aurais-tu un lien précis concernant ce projet ?

Typo

What's new !

Pour une supervision professionnelle : Nagios + Oreon

• [^]Re: Pour une supervision professionnelle : Nagios + Oreon

  Posté par thomas () le 10/02/2006 à 20:29. (lien). É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 Jean-Baptiste Sarrodie () le 11/02/2006 à 08:51. (lien). É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 mr_moustache () le 11/02/2006 à 06:19. (lien). É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 Jean-Baptiste Sarrodie () le 11/02/2006 à 08:58. (lien). É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 Gazel () le 11/02/2006 à 10:23. (lien). É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 Jean-Baptiste Sarrodie () le 11/02/2006 à 10:47. (lien). É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 Raphaël SurcouF (Jabber id, page perso, ) le 12/02/2006 à 03:28. (lien). É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 Jean-Baptiste Sarrodie () le 12/02/2006 à 11:01. (lien). É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 Raphaël SurcouF (Jabber id, page perso, ) le 12/02/2006 à 12:09. (lien). É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 julio234 () le 13/02/2006 à 10:13. (lien). É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 :)

    • [^]Re: Pour une supervision professionnelle : Nagios + Oreon

      Posté par Raphaël SurcouF (Jabber id, page perso, ) le 13/02/2006 à 13:42. (lien). Évalué à 1.

      En effet, ce serait effectivement plus simple ;-)
      Si tu es le Julio auquel je pense, j'ai bien vu que Romain avait résolu normalement plusieurs de mes bogues déjà ouverts mais je n'ai pas trouvé les modifications dans le cvs...
      Vivement la 1.3-RC1 que je vois tout ça ! ;-)

      • [^]Re: Pour une supervision professionnelle : Nagios + Oreon

        Posté par julio234 () le 13/02/2006 à 14:51. (lien). Évalué à 1.

        Normal, la configuration a été reprise a 0. Si tu la mettais sur ta base de données actuelle, cela ne fonctionnerai pas :). nous la mettrons en ligne une fois que l'on pourra la faire fonctionner.
        
        patience :)