Le projet Nagios est un moniteur de supervision, successeur de NetSaint. Il permet une supervision de serveurs, équipements 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.
Bonne supervision de vos serveurs et services ! Le projet Nagios est composé des éléments distinctifs suivants :
- Le moteur Nagios, qui passe en version 3.0, c'est le cœur de la solution, l'ordonnanceur ;
- Les greffons Nagios, en version 1.4.11, ce sont les sondes exécutées par l'ordonnanceur ;
- Des add-ons, environ 200 extensions disponibles.
Seuls les deux premiers éléments sont indispensables si vous voulez mettre en œuvre une solution basée sur Nagios.
Aller plus loin
- Nagios (51 clics)
- Les nouveautés 3.0 (31 clics)
- Changelog (2 clics)
- Téléchargement (35 clics)
# Déploiement
Posté par ʭ ☯ . Évalué à 7.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Déploiement
Posté par alexissoft . Évalué à 4.
Ensuite bon, le ministère de la santé était pas du tout à l'époque un ministère qui préconisait le libre, ils ont été forcé d'installer deux serveurs de tests sous Redhat, mais rien de plus.
[^] # Re: Déploiement
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
# Beau produit :)
Posté par Benjamin (site web personnel) . Évalué à 7.
Je conseille Nagios à tous ceux qui doivent superviser des machines serveurs ou stations.
[^] # Re: Beau produit :)
Posté par Eric MOREAU . Évalué à 1.
Je viens tout juste de m'inscrire sur ce forum en quête d'informations sur un produit que vous semblez particulièrement bien connaître, j'ai nommé "Nagios".
Pour ma part, je débute sous Linux et n'ai jamais utilisé Nagios !
J'ai donc tout naturellement quelques questions à poser à la communauté, si tant est que vous souhaitiez/puissiez y répondre.
En fait, Nagios fait partie d'un projet que je dois mener à bien dans le cadre de ma soutenance à un stage en entreprise. Mes neurones ne sont plus très jeunes et j'ai besoin des conseils avisés des spécialistes du sujet...
Sans plus attendre, voici quelques-unes de mes interrogations:
- Est-ce qu'un newbee peut se débrouiller d'un tel projet en ayant lu la documentation au préalable?
- Quels sont les points délicats/bloquants de Nagios, histoire de ne pas perdre trop de temps?
- Quels sont les avantages de Nagios en termes économiques ?
- Quels sont les + indéniables pour un Système d'Information à posséder cette solution?
- Son exploitation mobilise-t'elle une personne?
- Les alertes sont-elles facilement remontées par SMS ?
- Faut-il nécessairement installer un client sur tous les postes à superviser ?
- Etc.
En vous remerciant par avance pour les éventuels éléments de réponse de vous voudrez bien m'apporter.
Bien cordialement
Eric
# IHM
Posté par Frédéric Massot (site web personnel) . Évalué à 2.
- http://www.centreon.com
Quelques captures d'écran :
- http://www.centreon.com/Product/Screenshots.html
[^] # Re: IHM
Posté par matt23 . Évalué à 7.
Des bugs très très génants (perte de données de performance par exemple), des bugs d'interfaces, des bugs dans la gestion des process nagios.
Bref, on est très très loin de la qualité de Nagios.
Sans parler du script d'installation, une véritable boucherie, avec des choix pour le moins discutable.
Je conseillerai plutot de regarder Lilac, pour la configuration, et PNP (PNP is Not Perfparse) pour la gestion des données de performances.
Sinon, le projet Vigilo http://www.projet-vigilo.org/site/ semble très prometeur.
[^] # Re: IHM
Posté par bubar🦥 (site web personnel) . Évalué à 0.
Il pourrait aussi y avoir bientôt BIP vu que les dev et le client sont ok pour le libérer (reste à convaincre les patrons des dev ... qui devraient se laisser convaincre par le client :p ). Certes, BIP ne dispose pas de plugin vrml... mais BIP surveille déjà plus de 20 000 unix (hp-ux solaris linux) en europe. Et sa v2 prends en charge windows... donc sera déployée sur 200 000 petits postes...
Le MySQL derrière, faut qu' il tienne le choc ;)
Blague à part, l' interface web est 'extremement' complexe de part la quantité de possibilites disponibles. Il faut compter 2 jours d' utilisation avant de commencer à entrevoir les possibilités! Et un plugin vmrl sera Extra :)
Esperons que ce projet sera effectivement libéré. Deux raisons essentielles : il me semble que la solidité et l' efficacité de BIP intéresseront de très nombreuses personnes (physiques et morales). Et d' un autre côté il est probable que des contributions puissent être possibles, pour l' ihm web par exemple. (je ne sais pas si des contrib externes seraient acceptées, mais bon, on peut réver...)
Libérez BIP, libérez BIP ! :)
ps : BIP est une censure, en attendant que son petit nom puisse être donné lors de sa libération.
ps 2 : le principal dev. de BIP est aussi actuellement le dev. de compbench : un benchmark de compilation de certains logiciels pour gcc. http://compbench.sf.net
[^] # Re: IHM
Posté par Nÿco (site web personnel) . Évalué à 2.
[^] # Re: IHM
Posté par Romain Le Merlus . Évalué à 4.
Je peux citer a ce titre le moteur de template Smarty, quelques libraires PEAR assez pratiques (Quickform, DB...) ou encore RRDTool.
Il existe il est vrai quelques failles de sécu, mais des contributeurs bienveillants les remontent et nous donnent les pistes pour les corriger.
Le script d'installation est un reliquat de la version 0.01 de Centreon et a été repris de 0 pour la prochaine version 2.
Donc mis à part le dernier point, je te trouve vraiment dur avec le produit, et tes critiques largement injustifiées, surtout que l'équipe travaille dur sur la prochaine version 2.
Quand à Vigilo, deux choses, soit c'est un coming out qui explique ton post, soit tu ne l'as pas encore eu entre les mains ;-)
[^] # Re: IHM
Posté par julio234 . Évalué à 2.
https://sourceforge.net/project/stats/detail.php?group_id=21(...)
Mais les problèmes sur centreon, remontez les !! Y a un bugtracker... La on travaille sur le .deb, le RPM etc etc. Et pour la version 2, comme le dis rom, l'install a été pas mal modifié... Fini tout les scripts auto..
[^] # Re: IHM
Posté par matt23 . Évalué à 1.
Ce projet est développé par C-S, en interne, et, peu à peu, il passe en en libre. Le dépot sf ne sert visiblement qu'a publier les sources rendues libre.
Pour mesurer l'activité autour de ce projet, il va falloir attendre un peu et voir si les promesses sont tenues :
http://www.projet-vigilo.org/site/feuille_de_route
Pour les changements sur Centreon, j'attends d'avoir du temps libre pour y regarder et donner mon avis.
[^] # Re: IHM
Posté par ut0mt8 (site web personnel) . Évalué à 2.
Le négatif : les vues de monitoring ne sont pas utilisables sur de gros réseaux avec beaucoup d'equipements (pas de notion de unhandled problems, pas de tactical overview).
Bref notre NOC est revenu a l interface de nagios pour tous ce qui est monitoring. La configuration se fait toujours via centreon. (mais pour moi c'est encore plus simple avec des scripts et des flats file .csv).
J'attends avec impatience la version 2.0 qui se basera enfin sur NDO.
Pour les commentaires sur le code : je trouve ca sévere, c'est pas trop mal codé, c'est fait en smarty et l'organisation est pas vue (les topology par exemple). Le modele de la base de données est compréhensible; et c'est déjà grand.
Donc pour moi c'est un bon projet , mais trop axé sur les outils de reporting, graphs, maps et qui a oublié que l'essentiel pour un outil de monitoring c'est d'avoir des vues claires pour les exploitants.
[^] # Re: IHM
Posté par Cereal Killer . Évalué à 3.
Pour la petite histoire, la première fois que centreon est arrivé dans la boite qui m'emploie, c'était un stagiaire qui l'avait installé et face aux enormité du script d'install je lui avait dit d'arrêter le massacre :)
Quand je m'y suis remis quelques mois plus tard, l'install était toujours aussi merdique mais elle ne se fait qu'une fois. Et non seulement l'install est pas top, mais les maj non plus. :/
Sinon pour les bons côtés de la chose, c'est pour moi l'interface (même si elle est loin d'être parfaite) la plus sexy, et la plus pratique de nagios. et c'est bien tout ce qu'on demande à une interface. J'apprécie particulierement le fait qu'on puisse administrer nagios (création d'host, de services, etc ...), utilisé nagios (visualisation des alertes) et exploiter les données de perf avec le même logiciel.
Je pense que le projet dans sa version 1.X n'était pas suffisemment aboutis et pas vraiment destiné à la grosse production (beaucoup de bug sus-cité très genant) et j'attend donc beaucoup de la 2.0 qui m'a l'air bien plus lissé et ouverte aux grosse prod ou aux nombreux environnements.
J'éspère que la migration vers la 2.0 se fera en douceur et que tout se stabilisera vite.
Bref, vivement la v2 et longue vie à centreon!
[^] # Re: IHM
Posté par nomorsad . Évalué à 5.
J'avoue que je me suis fait peur avec le nombre de dépendances et même pas un RPM à se mettre sous la dent.
Et le pire, c'est que ma Suzette SLES 10.1 ne possède pas certains packages qu'il faut donc installer à la main (arg) .
Il aurait ensuite fallu que je launche un infâme ./install.sh (arg²) sur un serveur de production (aaarrg). J'y ai d'ailleurs entrevu des stop apache/mysql à la barbare et autres joyeusetés donc j'ai même pas essayé!
J'avais déjà galeré à configurer les fichiers de config Nagios sur mon pauvre parc de 20 serveurs.
Trucs et Astuces : créer à la voler vos config nagios à partir de fichiers CSV ou similaires, vous perdrez du temps en codage Perl, mais au final, vous gagnerez en maintenance!! Ceux qui ont déjà vu un fichier de config Nagios me comprendront !
J'ai beaucoup de respect pour les logiciels libres, et ce projet est légitime par le simple fait d'exister. Et j'ose à peine critiquer, car je sais que je pourrais à la rigueur m'impliquer dans l'amélioration de ces points...
Mais la, c'en était trop...
[^] # Re: IHM
Posté par nomorsad . Évalué à 5.
Non sérieusement, je me moque, mais je pourrais pas m'en passer.
# Ah! Nagios....
Posté par Barnabé . Évalué à 9.
*** common/objects.c:
add_host[627]
host *add_host(char *name, char *display_name, char *alias, char *address, char *check_period, int initial_state, double check_interval, double retry_interval, int max_attempts, int notify_up, int notify_down, int notify_unreachable, int notify_flapping, int notify_downtime, double notification_interval, double first_notification_delay, char *notification_period, int notifications_enabled, char *check_command, int checks_enabled, int accept_passive_checks, char *event_handler, int event_handler_enabled, int flap_detection_enabled, double low_flap_threshold, double high_flap_threshold, int flap_detection_on_up, int flap_detection_on_down, int flap_detection_on_unreachable, int stalk_on_up, int stalk_on_down, int stalk_on_unreachable, int process_perfdata, int failure_prediction_enabled, char *failure_prediction_options, int check_freshness, int freshness_threshold, char *notes, char *notes_url, char *action_url, char *icon_image, char *icon_image_alt, char *vrml_image, char *statusmap_image, int x_2d, int y_2d, int have_2d_coords, double x_3d, double y_3d, double z_3d, int have_3d_coords, int should_be_drawn, int retain_status_information, int retain_nonstatus_information, int obsess_over_host){
*** xdata/xodtemplate.c:
xodtemplate_register_host[10368]
new_host=add_host(this_host->host_name, this_host->display_name, this_host->alias, (this_host->address==NULL)?this_host->host_name:this_host->address, this_host->check_period, this_host->initial_state, this_host->check_interval, this_host->retry_interval, this_host->max_check_attempts, this_host->notify_on_recovery, this_host->notify_on_down, this_host->notify_on_unreachable, this_host->notify_on_flapping, this_host->notify_on_downtime, this_host->notification_interval, this_host->first_notification_delay, this_host->notification_period, this_host->notifications_enabled, this_host->check_command, this_host->active_checks_enabled, this_host->passive_checks_enabled, this_host->event_handler, this_host->event_handler_enabled, this_host->flap_detection_enabled, this_host->low_flap_threshold, this_host->high_flap_threshold, this_host->flap_detection_on_up, this_host->flap_detection_on_down, this_host->flap_detection_on_unreachable, this_host->stalk_on_up, this_host->stalk_on_down, this_host->stalk_on_unreachable, this_host->process_perf_data, this_host->failure_prediction_enabled, this_host->failure_prediction_options, this_host->check_freshness, this_host->freshness_threshold, this_host->notes, this_host->notes_url, this_host->action_url, this_host->icon_image, this_host->icon_image_alt, this_host->vrml_image, this_host->statusmap_image, this_host->x_2d, this_host->y_2d, this_host->have_2d_coords, this_host->x_3d, this_host->y_3d, this_host->z_3d, this_host->have_3d_coords, TRUE, this_host->retain_status_information, this_host->retain_nonstatus_information, this_host->obsess_over_host);
[^] # Re: Ah! Nagios....
Posté par reno . Évalué à -1.
Je ne devrais pas poser la question vu le code pourri que j'ai déjà vu (dans un autre style), mais l'espoir fait vivre..
[^] # Re: Ah! Nagios....
Posté par Anonyme . Évalué à 0.
Enfin bon, c'est pas comme si c'était le seul projet à avoir un code immonde... :-(
[^] # Re: Ah! Nagios....
Posté par Stéphane P. . Évalué à 6.
[^] # Re: Ah! Nagios....
Posté par Sébastien Huss . Évalué à 6.
wahoo,
Tu as choisi la définition de la plus grosse fonction et un appel à cette dernière.
Visiblement, un noeud, pour Nagios, à beaucoup de propriété, ce qui en soit n'est pas gênant au contraire : Cela veux dire que Nagios est très flexible...
Dis moi, que préfères-tu ?
- 1 appel à une fonction gros comme ca,
ou
- 55 appels à des fonctions différentes, sans avoir de garanti que in fine le noeud sera correct :
new_host=create_host(this_host->host_name);
set_display_name(new_host, this_host->display_name);
set_alias(new_host, this_host->alias);
....
Sachant que chacun de ces appels de fonctions entraine un contexte switch, cad des cycles de pénalités (j'ai plus le chiffres en tete, mais beaucoup).
</bourin>
Honnêtement, un outil de monitoring dois générer le minimum d'over-head possible. Donc il faut que sont code soit relativement optimisé. De fait, je trouve ces lignes plutôt intéressantes.
Dis moi, sur la prochaine dépêche parlant de xorg, vas-tu nous parler de la fonction (à peine utilisé) XCreateSimpleWindow, qui contrairement à son nom à globalement le même nombres de paramètres à ceci près c'est que ce ne sont pas des int et autre char * mais plutot des XRect, XDisplay etc qui sont déjà crée par l'appel de fonction pas simple non-plus.
Bref,
bien à toi
Sébastien
[^] # Re: Ah! Nagios....
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 10.
Ce qui est plus lisible, plus simple à utiliser.
[^] # Re: Ah! Nagios....
Posté par Barnabé . Évalué à 10.
Pour l'exemple de la fonction add_host, je ne suis vraiment pas certain que de déposer 55 objets sur la pile soit plus optimal que de simplement passer le pointeur sur la structure déjà remplie.
[^] # Re: Ah! Nagios....
Posté par Anonyme . Évalué à 3.
[^] # Re: Ah! Nagios....
Posté par _flo_ . Évalué à 3.
Prends garde à pas tout mélanger non plus. Un appel de fonction, c'est effectivement quelques opérations :
1) 'push' des parametres et du pointeur de retour sur la pile d'appel
2) 'jump' vers le code de la fonction
3) 'pop' des parametres
4) execution du code de la fonction
5) 'jump' vers le pointeur de retour
Mais rien de monstrueux sauf, quand c'est une fonction très courte appelée très souvent auquel cas l'overhead est grand et on peut utiliser l'inlining (copie du code de la fonction).
Rien a voir avec un 'context-switch', qui est une opération effectuée par le noyau et qui consiste en sauver le contexte d'exécution quelque part (registres, pointeur d'instruction courant etc...) et de le remplacer par un autre. Ce qui arrive dans 2 cas (en gros) :
- changement de tache par l'ordonnanceur
- appel système (passage du mode utilisateur au mode noyau)
Et un context switch est effectivement très gourmand, par rapport a un appel de fonction en tout cas ;-).
Comme le dis très justement quelqu'un plus bas, passer 270000 paramètres sur la ligne de commande ce n'est pas "optimisé", loin de là (par rapport a ce qu'on a vu plus haut, ca fait 270000 push et pop) par rapport a un passage sur la pile d'un ptr vers une structure pré-remplie.
[^] # Re: Ah! Nagios....
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
On ne peut pas en dire autant de tous les projets dont la forme laisse à désirer (et puis bon, si tu voyais le code de la majorité des plugins de Nagios, tu partirais en courant).
[^] # Tournure d'esprit
Posté par Kerro . Évalué à 4.
Nagios est peut-être programmé par des admins. Et les admins ont peut-être une tournure d'esprit qui ne correspond pas aux canons des "vrais" programmeurs.
Ou pas :-)
# NagVis
Posté par FRLinux (site web personnel) . Évalué à 3.
Pour ceux qui veulent du beau pour montrer a leur boss, il y a un beau frontend nomme : NagVis (http://www.nagvis.org/)
[^] # Re: NagVis
Posté par Raphaël SurcouF (site web personnel) . Évalué à 6.
# Migration de la version 2 vers la version 3
Posté par nicolargo (site web personnel) . Évalué à 10.
http://blog.nicolargo.com/2008/03/migration-facile-de-nagios(...)
A+
# Plugin Nagios pour Cacti
Posté par Frédéric Mangeant (site web personnel) . Évalué à 5.
* Nagios data is handled via ndo2db (written/maintained by Nagios team)
* A customizable dashboard view with various portlets to choose from
* Tabbed interface (EXT) with asynchronous data loads
* Must be a complete Nagios UI replacement (reports, maps, etc.)
* Must import (graph) Nagios performance data (semi-auto)
* Ability to link existing Cact service/host graphs to Nagios service/host
* Host and service level permissions configured similar to Cacti
[^] # Re: Plugin Nagios pour Cacti
Posté par vjm . Évalué à 5.
Pour ce qui est du plugin NPC, je suis content de voir que l'auteur est revenu mais la dernière fois il avait déjà montré un début pas mal puis plus aucune information et le code disparu, plus moyen d'essayer de continuer. J'espère qu'il va pas nous refaire le coup, là on est quasiment à 1 mois sans nouvelles.
C'est clair qu'il y a un gros besoin d'une interface un peu plus clean à Nagios, suffit de voir le nombre de projets qui s'y attelent, de Centreon (qui vraiment horrible) à GroundWork en passant par Vigileo ou même NaReTo. Je crois que le drame c'est que Nagios et ses plugins soient devenus tellement incontournables que tout le monde essaye d'en gaumer les défauts (la configuration, la visualisation) au lieu de repartir de quelque chose de clean.
Pour avoir beaucoup travailler dessus, je pense qu'à moyen-terme, Cacti, une fois la Plug In Architecture intégrée nativement, sera une super base pour se recréer un système de supervision clean et efficace.
[^] # Re: Plugin Nagios pour Cacti
Posté par mcben . Évalué à 5.
Pour développer au quotidien autour de Cacti, je ne suis pas sûr que Cacti soit une si bonne base que ça pour faire un "système de supervision clean et efficace". En tous cas, pas plus que Nagios :
* Le schéma de BDD est horrible (énormément de redondance d'infos, "templates" et données créées à partir de ces mêmes templates dans la même table).
* Le code PHP est quand même bien crade : en plus d'être "oldschool" (ex: pas de PHP5), beaucoup de fonctions énormes, etc..
Donc y a encore du boulot.
LE point fort de Cacti sont ses templates : l'idée de base est excellente. Par contre, l'implémentation laisse vraiment à désirer :/
[^] # Re: Plugin Nagios pour Cacti
Posté par vjm . Évalué à 4.
Par contre c'est clair que le gros point noir dans Cacti c'est le schéma SQL qui est vraiment dégueulasse. Je me suis rendu compte quand je voulais voir si on pouvait pas mettre en place un cleanup lorsqu'on avait fini de jouer/tester un plugin (qui ajoute encore des tables et pas toujours de façon très propre) et déjà que j'étais pas fan de SQL à la base, ça m'a un peu coupé l'envie.
Par contre à l'utilisation, templates + plugins, ça poutre tous les autres outils que j'ai pu essayer.
[^] # Re: Plugin Nagios pour Cacti
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Peux-tu développer ? Sous Nagios, il y a également des templates.
Je présume que tu voulais parler des templates pour les graphiques, non ?
Je pense qu'il est prématuré de jeter dos-à-dos Cacti et Nagios car les deux projets ont des similarités mais poursuivent des buts bien différents et se retrouvent assez complémentaires.
Pour autant, je regrette que le réseau soit surchargé par des requêtes redondantes par l'emploi simultané de Cacti et Nagios.
[^] # Re: Plugin Nagios pour Cacti
Posté par Frédéric Mangeant (site web personnel) . Évalué à 2.
L'architecture plugin (PIA) est intégreé dans le SVN de la version 0.8.8 :-)
# Hobbit ?
Posté par oau . Évalué à 2.
Alors que hobbit est d'une simplicité déconcertante et d'une souplesse très agréable. Ok le résultat est pas super sexy mais il est très très efficace.
En tout cas je l'utilise et je pousse ma boite à l'utiliser. En remplacement de cette horreur de SRM dans un premier temps et peut être de tivoli/patrol un jour. En tout cas dans ma boite précédente c'est ce qui a été fait. Remplacer patrol,netview,what'up et un truc pour vérifier des urls par hobbit.
[^] # Re: Hobbit ?
Posté par Frédéric Mangeant (site web personnel) . Évalué à 4.
Chez nous il supervise ~ 4.500 équipements (~ 25.000 points de supervision, la plupart étant l'équivalent des "passive checks" de Nagios avec des clients Hobbit installés sur les machines Unix/Windows).
Pour moi ses gros avantages sont sa rapidité de mise en place, sa fiabilité, sa capacité à monter en charge (via l'ajout de serveurs Hobbit pour les tests réseau, de proxies pour les "passive checks") et sa compatibilité avec les scripts Big Brother.
Des "plugins", comme Devmon, pour une supervision SNMP assez pousée basée sur des templates, ainsi que BBwin, client Hobbit pour Windows développé par un français, le rendent encore plus efficace.
Par contre, le fait que l'unique développeur de la partie Unix de Hobbit soit (AMHA) assez fermé, sorte des patches pas vraiment référencés et n'ait pas sorti de version stable depuis 18 mois font que si c'était à refaire, je pencherais peut-être vers Nagios...
Pour ceux qui utilisent Hobbit, la version 4.3 va proposer la détection de "bagotements" (flapping), la gestion des jours fériés/vacances (pour les règles d'alarme), une gestion native de SNMP, des stats sur les machines ayant le plus de changements d'états, etc.
[^] # Re: Hobbit ?
Posté par Nÿco (site web personnel) . Évalué à 4.
[^] # HP Overload
Posté par Kerro . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.