Monitoring Oreon : sortie de la version 1.4

Posté par  . Modéré par j.
Étiquettes :
0
30
mar.
2007
Communauté
L'équipe du projet Oreon est heureuse de vous avertir de la publication de sa dernière version : Oreon 1.4. Oreon sort dorénavant du cadre "frontend pour Nagios" en apportant davantage de fonctionnalités. Ainsi, grâce à cette seule application, vous contrôlez une solution complète de supervision réseau.

Fonctionnalités de Oreon :
  • Configuration simple du périmètre, basé sur une arborescence de modèles
  • Monitoring basé sur le moteur Nagios (2.8)
  • Totale flexibilité dans la nature et les moyens de remonter les informations
  • Exploitation en profondeur des logs et des données de performance
  • Moteur graphique RRDTool pour un rendu "Cacti"
  • Rétention et stockage des données totalement paramétrable
  • Reporting temps réel et historisation
  • Administration simple et puissante
  • Solution a destination des initiés et non initiés
  • Conception modulaire : Intégration de NTOP et PHP-Weathermap
  • Modules de cartographie avancée et calcul de SLA

Oreon bénéficie de services de garantie et de support de la part d'une entité professionnelle.

Aller plus loin

  • # Hummm ...

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

    Ça serait pas mal de préciser ce que c'est, et à quoi ça sert, pour les gens qui ne sont pas abreuvés à longueur de journée par des "RDDTool", des "NTOP" et autres "SLA". Je pense qu'un petit copier coller depuis la page principale du projet ne ferait pas de mal.

    Sinon, les gens dans la "vraie vie" ils risquent de véhiculer une image stéréotypée des Geek *N*Xiens (et xBSDiste !).

    Adhérer à l'April, ça vous tente ?

  • # Swap et ext2

    Posté par  . Évalué à 2.

    http://www.oreon-project.org/images/stories/screenshots/2007(...)

    C'est normal que l'outil rapporte que la partition swap ('Swap Space') soit en ext2fs ? (je suppose que 'hrFSLinuxExt2' correspond à ext2fs).

    • [^] # Re: Swap et ext2

      Posté par  . Évalué à 1.

      C'est uniquement basé sur des retours SNMP... Y a peut etre un soucis a ce niveau la.

      • [^] # Re: Swap et ext2

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

        À voir le tableau, on dirait plutôt qu'il s'est emmêlé les pinceaux.
        Si je prends ma station personnelle comme exemple :

        $ snmpwalk -Os -v 2c -c public localhost hrFS
        ...
        hrFSMountPoint.1 = STRING: "/"
        hrFSMountPoint.2 = STRING: "/sys"
        hrFSMountPoint.3 = STRING: "/proc/bus/usb"
        hrFSMountPoint.4 = STRING: "/home"
        hrFSMountPoint.5 = STRING: "/usr"
        hrFSMountPoint.6 = STRING: "/var"
        hrFSMountPoint.7 = STRING: "/proc/sys/fs/binfmt_misc"
        ...
        hrFSType.1 = OID: hrFSLinuxExt2
        hrFSType.2 = OID: hrFSOther
        hrFSType.3 = OID: hrFSOther
        hrFSType.4 = OID: hrFSLinuxExt2
        hrFSType.5 = OID: hrFSLinuxExt2
        hrFSType.6 = OID: hrFSLinuxExt2
        hrFSType.7 = OID: hrFSOther

        Dans les tables de hrFS, ça semble correct mais les données de la première colonne correspondent plutôt à celles de hrStorageDescr :

        $ snmpwalk -Os -v 2c -c public localhost hrStorageDescr
        hrStorageDescr.1 = STRING: Physical memory
        hrStorageDescr.3 = STRING: Virtual memory
        hrStorageDescr.6 = STRING: Memory buffers
        hrStorageDescr.7 = STRING: Cached memory
        hrStorageDescr.8 = STRING: Shared memory
        hrStorageDescr.10 = STRING: Swap space
        hrStorageDescr.31 = STRING: /
        hrStorageDescr.32 = STRING: /sys
        hrStorageDescr.33 = STRING: /proc/bus/usb
        hrStorageDescr.34 = STRING: /home
        hrStorageDescr.35 = STRING: /usr
        hrStorageDescr.36 = STRING: /var
        hrStorageDescr.37 = STRING: /proc/sys/fs/binfmt_misc

        Pour obtenir la correspondance, il faudrait s'appuyer sur la table hrFSStorageIndex :

        $ snmpwalk -Os -v 2c -c public localhost hrFSStorageIndex
        hrFSStorageIndex.1 = INTEGER: 4
        hrFSStorageIndex.2 = INTEGER: 5
        hrFSStorageIndex.3 = INTEGER: 6
        hrFSStorageIndex.4 = INTEGER: 7
        hrFSStorageIndex.5 = INTEGER: 8
        hrFSStorageIndex.6 = INTEGER: 9
        hrFSStorageIndex.7 = INTEGER: 10

        Or, d'après la description de hrFSStorageIndex, il s'agit de l'index de la table hrStorageEntry et on peut déjà constater certaines différences. En effet, le premier index de la table hrFS semblerait correspondre au quatrième index de la table hrStorage. Non seulement l'index en question n'existe pas dans la seconde table mais les autres index ne correspondent pas...
        Si les correspondances d'index peuvent s'avérer défaillantes, il vaudrait mieux s'appuyer sur une comparaison entre hrStorageDescr et hrFSMountPoint.

  • # SOAP blah

    Posté par  . Évalué à 1.

    Vous savez s'il y a moyen de piloter Oreon voire même Nagios par le biais d'un canal de type SOAP/XML-RPC ?
    ("Piloter" == "possibilité de créer des Hosts, etc...")

    • [^] # Re: SOAP blah

      Posté par  . Évalué à 1.

      Pas à ma connaissance. Avec Nagios y'a des projets indépendants pour avoir une interface SOAP ou XML-RPC pour accéder au status d'hôtes mais rien pour piloter complétement. Et vu qu'Oreon c'est quand même essentiellement une belle interface conviviale regroupant Nagios et Cacti (comme la vacuité de certaines expressions de l'annonce genre "administration simple et puissante" ou "totale flexibilité dans la nature et les moyens de remonter les informations" pouvait le laisser penser), je doute qu'ils aient développé ça de leur côté. En tous cas j'ai pas trouvé.

      • [^] # Re: SOAP blah

        Posté par  . Évalué à 1.

        Une application java existe pour visualiser les données de oreon dans un client lourd (JRE avec framework eclipse). Les données sont sous plusieurs formats :graphs, vues topologiques, vues metier...

        Ensuite peut etre cette interface pourra etre diversifiée a plus de fonctionnalités...

  • # Dommage...

    Posté par  . Évalué à 4.

    Bonjour,

    Tout d'abord, un grand bravo à toute l'équipe d'Oréron, un outil que je mettrais bien en production dans la société ou je travaille !!

    Sauf que, dommage mais nous avons déjà un Nagios et de nombreux Cacti en production, que les installations de ces services ont été customisées (ainsi que pour Apache). Que les fichiers de configurations de Nagios sont générés automatiquement en fonction de notre parc de serveurs... bref, un joli petit sac de noeud.

    Et pourquoi ne puis je pas mettre Oreon en service ? Tout simplement parce que :
    - je ne fais pas confiance à l'installeur (install.sh) (comment ca, je suis parano ?)
    - je n'ai pas le temps de reproduire une partie de notre environnement de production pour y mettre un Oreon par dessus en test
    - je n'ai trouvé nulle par une documentation qui explique comment installer Oréon pas à pas (comme pour Nagios par exemple) (pas beaucoup cherché, c'était à l'époque de la sortie de Oréon 1.3)
    - je n'ai pas le temps de décortiquer le script d'install pour tout refaire proprement

    Je sais, je rale pour rien, tout est la, à porté de main pour enfin arrété de baver et mettre en prod quelque chose de beau qui réunisse nos infos Nagios et Cacti... mais... j'ai pas le temps de m'y mettre :'(

    Alors, si quelqu'un dans l'assistance pouvait gentillement m'aiguiller sur une documentation d'install (sans passer par le install.sh), je l'en remercie d'avance !

    Sur ce, bonne continuation, et bravo pour le travail accompli

    Sinon, promis, dès que j'ai le temps de mettre un Oréon en prod, je vous donne une doc d'install pas à pas pour avoir un Oréon aux petits oignons !

    • [^] # Re: Dommage...

      Posté par  . Évalué à 2.

      Me dis pas quand meme que t'as redecortiqué le ./configure de nagios :)

      Nan mais le install.sh ne fait rien d'extraordinaire à part copier des fichiers, ajouter des cron et copier de plugins de nagios... Biensur il y met des droits et tout ce qui va avec...

      Et si tu nous avais contacté t'aurai pu avoir une doc :)

      Apres pour ce qui est de ton script qui genere les confs de nagios en auto, car tu peux toujours le faire... une bidouille maison comme tu as fait et hop c fini.

      De plus avec oreon tu peux loader tous tes anciens fichiers nagios direct dans la base oreon. J'ai des clients qui le font. Donc ça prendra pas trop de temps. En plus reunir les deux (nagios + cacti) te permet de ne plus avoir de cacti car les données de nagios sont graphées direct => soit 1 get pour le check + la donnée dans le graph :)

      Si tu as envie d'une demo, n'hesite à nous contacter infos@oreon-project.org. Ou meme pour tout autre question ou conseil :)

      • [^] # Re: Dommage...

        Posté par  (Mastodon) . Évalué à 6.

        Pour être dans la même situation que Fouyaya (parc de machines monitorées par le tandem nagios/cacti), je me suis aussi intéressé à oreon.

        Ben je n'éprouve aucun plaisir à insulter le travail des autres, mais le install.sh fourni avec oreon était un vrai danger public. Il ne faisait aucune vérification quand à l'environnement dans lequel il était executé, et n'avait semble t-il été testé que sur debian linux.

        Bref sur une machine Solaris, il se chiait dessus toutes les deux lignes parce qu'il assumait de chemins par défaut ou qu'il s'attendait à des outils avec une syntaxe GNU. Bref j'avais commencé à le réécrire, puis j'ai laissé tomber par manque de temps.

        Cela étant dit, je trouvais la doc d'installation un peu maigrichonne, ce qui m'a aussi poussé à abandonner le test d'oreon. Rien que ça, ça fait tellement cheap qu'on a aucune envie de mettre un tel produit en prod :


        ENGLISH :
        ---------

        For install only :

        Launch "./install.sh"

        For more informations, mail infos@oreon-project.org or visit Oreon's forum http://forum.oreon-project.org

        Thanks for using oreon.

        • [^] # Re: Dommage...

          Posté par  . Évalué à 1.

          Et Oui développé sur fedora et Mandriva, et adapté pour debian. Pas testé pour solaris. On attend un travail de la communauté pour pas mal de choses.

          Pourquoi n'es tu pas allé plus loin ?? :) C'est ca les produits communautaires :)

      • [^] # Re: Dommage...

        Posté par  . Évalué à 2.

        Au niveau du script d'install t"'as quand même raison de te méfier.

        Il fait des chmod 775 et autres brutalités comme des start/stop sur apache ou bien il prend des décisions arbitraires sur quels scripts de /etc/init.d/ utiliser (apache? apache2? nagios? nagios?, le premier qu'il trouve)

        Le chmod -R 775 m'a bien fait rigoler une fois quand j'ai mis /usr comme préfixe d'installation de nagios (et oui, si le nagios vient d'un paquet son préfixe est /usr et pas/usr/local/nagios, à priori). Un petit chmod -R 775 dans /usr ça fait mal :-) ca va jusqu'à virer les setgid et setuid de pas mal de programmes.

        Alleï bientôt des chmod -R 777 / dans les scripts d'install!

  • # Graphique : RRDTools ou Perfparse ?

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

    Dans la vidéo de présentation, les graphiques RRDTool font furieusement penser à ceux de Cacti : il y a même les petits icônes (la loupe et la clé anglaise) sur la droite ! J'ai toujours eu du mal à saisir l'orientation du projet Oreon sur ce point : Perfparse a été intégré depuis la version 1.2 (je crois) et maintenant, RRDTool refait surface... Qu'en est-il exactement ?

    • [^] # Re: Graphique : RRDTools ou Perfparse ?

      Posté par  . Évalué à 4.

      RRDTool a toujours ete dans Oreon, depuis la 0.1 meme.
      En fait nous avons ete tout le temps convaincu du potentiel de ce moteur de graph, les changements ont résidé dans la maniere de creer/visionner les données de performance.

      Le premier choix, et toujours fonctionnels, quoique nous ne le conseillons plus, est d'utiliser les plugins graphiques "check_graph". Ils renvoient des informations a Nagios (code d'erreur + output) et peuplent simultanement une base rrd physique.
      La limitation est qu'il faut retaper tous les plugins existants et que dans le cas de supervision distribuée c'est assez limité car les bases rrd sont crees à l'endroit d'exécution du plugin.

      Le second choix a été de créer des graphs rrd "a la volee" sur la base des metrics remontees dans perfparse (1.3.x). L'idée était bonne car nombre de plugins ont adopté ce format de retour d'informations et cela nous permet de centraliser les donnees.
      La limitation vient du fait que perfparse est assez lourd a entretenir et son schema SQL offre peu de liberte.
      Resultat, plusieurs secondes pour des graphs sur des periodes pas forcement enormes (et du coup qu'on veuille grapher plusieurs metrics dans le meme graph...) et dans le temps, la retention d'informations prend une place énorme.

      La troisieme solution, actuelle et très performante :
      Donner a l'utilisateur le choix dans sa remontee, bases rrd physiques et/ou base SQL, a partir des donnees de performances qui sont remontées.
      L'interet est qu'on a des bases rrd physiques, donc tres rapides a grapher et facilement manipulables (cacti, pnp styles) et que ceux qui le desirent peuvent stocker les donnees de performance dans un nouveau modele de base de donnees (Oreon Data Storage), plus light et optimisé que perfparse afin de conserver dans le temps ses donnees, ou alors pour une exploitation exterieure (reporting...).

      C'est mieux ? :p

  • # Interface

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

    Suis je le seul a penser que l'interface de Nagios est beaucoup plus claire que celle d'Oreon ?

    Dans la société ou je bosse on veux remplacer les Nagios par des Oreons, et bien les personnes ont beaucoup de mal a s'y faire. (OK je suis un peu de parti pris vu que c'est moi qui avait mis en place les Nagios).

    • [^] # Re: Interface

      Posté par  . Évalué à 2.

      Effectivement il a fallu faire des concessions par rapport a l'interface de Nagios et peut etre perdre un petit peu par rapport a la navigation originelle.
      Le fait est que maintenant, tu n'es pas perdant au change, on reprend la majeure partie des fonctionnalites de Nagios tout en ajoutant un lot tout aussi interessante.
      Oreon n'est pas simplement une reprise des pages existentes, mais avec le temps un outil qui le complete bien et le rend disponible a un large public.

      Si on avait voulu faire un framework qui liste les etats courants de ressources, je pense qu'on aurait pu faire mieux c'est vrai, mais en fait ce n'est pas ca Oreon...

      Je serais heureux de te faire une demo du produit pour que tu voies l'interet qu'il existe de passer sur du Oreon (pour ta boite et donc toi :p). Apres ca et un peu de pratique j'imagine qu'un Nagios addict comme toi aurait de bonnes remarques a nous faire suivre sur l'evolution du produit.

      ++

      • [^] # Re: Interface

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

        Je suis plutot d'accord sur le fait qu'Oreon fait plus de chose que Nagios; intégrer une solution de graphing est une bonne idée.
        Par contre point de vue supervision pure il y a des vues de Nagios indispensables qui n'ont pas été reprise. La tactical Overview de Nagios est celle qui manque le plus. Mais en fait à l'utilisation les vues Oreon sont beaucoup moins pratiques. Pas de vue synthétique de tout les services en Alertes non acknowlegdé, et puis a quoi sert la premiere page avec les camemberts sinon a faire joli ?

        Sinon merci pour la démo mais on déjà censé utiliser Oreon en lieu et place de Nagios (c'est pas gagné). D'ailleurs tu doit connaitre ma société vu que son nom apparait dans le slide show de présentation :/

        • [^] # Re: Interface

          Posté par  . Évalué à 2.

          Oui effectivement au niveau du monitoring dans les versions precedentes on manquait de filtres de vues. C'est quelque chose qui a ete retravaille, notamment les vues ou on separent les problemes acknowledges de ceux qui ne le sont pas.

          La tactical overview est bien sur plus pertinente que les camemberts de depart, et c'est par manque de temps (et oui bcp de gens attendaient quand meme cette version ;-) ), que nous avons decide pour la 1.4 de ne pas aller plus en profondeur sur la page de login. Mais comme tu t'en doutes, ca sera implemente dans les prochaines.

  • # Problèmes inérant à Nagios corrigés ?

    Posté par  . Évalué à 4.

    Avec Oreon est-il de changer des paramétrages de nagios sans devoir le redémarrer ?

    Est-ce que l'interface est capable de gérer plus de 10 machines ?
    Le problème de l'interface de nagios sans compter les problèmes
    avec son auteur principal qui refuse de prendre des patchs, est sa lourdeur
    dès qu'on essaie de travailler sur un véritable parc de serveurs...

    Pourquoi avoir choisis encore une fois de rendre les graph à la volée ?
    Ce n'est pas moins lourd de calculer les graphes une fois toute les 5 minutes ?
    Histoire de ne pas exploser la charge de la machine quand 3 personnes regardent les graphes ?





    • [^] # Re: Problèmes inérant à Nagios corrigés ?

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

      Avec Oreon est-il de changer des paramétrages de nagios sans devoir le redémarrer ?

      On n'a pas besoin de redémarrer Nagios, avec ou sans Oreon. Nagios comprend une option « reload ». Oreon ne peut pas corriger certains « défauts » internes de Nagios. En outre, et Oreon a intégré cette remarque de ma part, on peut demander Nagios de « redémarrer » via son fichier de commandes externes. En quoi cela te pose-t-il des problèmes avec Nagios ?

      Est-ce que l'interface est capable de gérer plus de 10 machines ?
      Le problème de l'interface de nagios sans compter les problèmes
      avec son auteur principal qui refuse de prendre des patchs, est sa lourdeur
      dès qu'on essaie de travailler sur un véritable parc de serveurs...

      Je ne vois pas le rapport entre « plus de 10 machines » et un « véritable parc de serveur ». J'ai déjà eu à mettre en place des plate-formes de supervision avec Nagios et plus de 10 machines. Bien sûr qu'Oreon est capable de gérer plus de 10 machines.
      En outre, l'un de mes collègues a déjà eu l'occasion de travailler sur des parc conséquents (on parle en milliers d'hôtes) et là, on a eu l'occasion d'écrire des patchs permettant aux CGI de gérer un tel nombre. Mais il s'agissait exclusivement d'affichage et non de gestion pure de la part du démon.
      Quant à l'attitude d'Ethan pour les contributions sous forme de patchs, je ne sais pas à quoi tu fais allusion mais on dirait que tu parles d'expérience. Peux-tu nous en dire plus ?

  • # A revoir

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

    Hi,

    J'ai tenté l'installation d'oreon, elle est assez mal conçue je trouve, c'est bête qu'il faille installer nagios et oreon à part, car cela fait perdre un gain de temps énorme. Et il semble qu'oreon est été développé pour apache1 ... vu les modifications qu'il a fallu faire ds install.sh pour installer oreon. Outil à revoir à mon goùt.

    Bye

    • [^] # Re: A revoir

      Posté par  . Évalué à 2.

      Oui je suis d'accord avec toi, mais nous ne sommes pas la non plus pour maintenir l'install de nagios. Si demain il y a changement il faudra alors réadapter...

      Nous avions développé cela au debut. Mais c'etait pas top. Nous avons décidé de l'abandonner. En plus c'est pas si sorcier... tout le monde y arrive en suivant la doc. et si jamais le script faisait l'installation d'une maniere et que des personnes preferent la faire d'une autre facon, on serait bon pour avoir des remarques comme celles ci-dessus.... :)

      Le plus simple dans ce cas la est de faire une rpm ou un deb avec gestion de dépendances... Cela va venir.

Suivre le flux des commentaires

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