Bug dans l'ordonnanceur Nagios 3
Peut être que certains d'entre vous s'en sont rendus compte sans comprendre ce qui se passait. Peut être que d'autres ne s'en sont pas rendus compte mais en sont les victimes. Un bug dans l'ordonnanceur de Nagios est en cours depuis maintenant quelques mois. Et il n'est toujours pas corrigé.
Qu'est ce qui se passe? Ce bug est assez insidieux dans le sens où il est possible de ne pas le détecter. Ce bug est le suivant: de temps à autre, il arrive que certains tests sont reprogrammés l'année prochaine. Imaginez un peu: je fais un test toutes les 15 minutes mais il s'avère que le prochain test est programmé le 09/03/2010. Oui oui: 2010. Soit dans un an. Le problème est que du coup, plus aucun test ne sera effectué jusque cette date pour ce service. Donc au prochain problème, il passera complètement inaperçu à la fois pour les administrateurs mais aussi pour la supervision.
Comment est ce possible? Ben... personne n'arrive réellement à diagnostiquer ce cas en fait. Il s'avère que ce bug n'est pas reproductible à coup sûr. Il intervient de manière inattendue. Certains voient se bug régulièrement. D'autres le voient uniquement lors des changements de mois. D'autres ne l'ont vu que lorsqu'un problème sur un serveur est apparu et que l'alerte a été donné par... les utilisateurs.
Comment corrigé? Pour l'instant aucun patch n'est disponible. Donc aucune correction aujourd'hui. Un contournement peut être? Non plus! Enfin, si! Un seul: pour chaque test, vérifier visuellement que le prochain test n'est pas programmé l'année prochaine. Dans ce cas, reprogrammer le prochain test à l'aide de l'interface Nagios (où celle de Centreon).
Quelles conséquences? Pour rappel, le principal travail de Nagios est de programmer des tests en fonction d'une configuration. Aujourd'hui, ce bug touche le coeur de Nagios. Donc cela écorne sévèrement l'image de celui-ci. En fait, le plus grave aujourd'hui est que ce bug dure depuis plusieurs mois et que le principal développeur de Nagios ne communique pas sur ce sujet. Aucune réponse aux mails sur la mailing-list. Pourtant ce n'est pas faute de l'en informer. C'est, je trouve, un manque de respect pour la communauté des utilisateurs de Nagios. Or, comme tout le monde le sait, ce qui fait vivre un Logiciel Libre, c'est sa communauté. Attention, Ethan à ne pas perdre le soutient de ta communauté.



Il est vrai que j'ai tenté de reproduire ce bug
Yannj | mercredi, mars 11 2009 | 21:30Il est vrai que j'ai tenté de reproduire ce bug sans succès.
C'est le genre de bug qui risque d'être résistant!
Quoi qu'il en soit il est tant qu'Ethan se penche sur la qualité de son code et sur sa façon d'intéragir avec la communauté... (si il veut éviter de voir un fork de nagios apparaître)
> (si il veut éviter de voir un fork de nagios
Cédric Temple | vendredi, mars 13 2009 | 12:45> (si il veut éviter de voir un fork de nagios apparaître)
Hou le gros mot! "Fork"! ça fait toujours peur. ;-) C'est un risque dont il n'a peut être pas conscience. Mais en même temps, j'ai vu peu de personnes "râler" au point d'aboutir à un fork. Pour l'instant en tout cas...
Bien le bonjour, Nous rencontrons aussi un
pydubreucq | vendredi, mars 20 2009 | 10:57Bien le bonjour,
Nous rencontrons aussi un problème avec l'ordonnaceur, mais par contre il ne rajoute pas un an, mais il enlève toute planification :(
Ce qui comme dit plus haut est fortement gênant :(
Voici ce que j'obtient :
Next Scheduled Check: N/A
Bonne journée ;)
Salut, j'ai eu exactement le même problème. Le
Jeannot | dimanche, avril 5 2009 | 20:09Salut,
j'ai eu exactement le même problème.
Le problème ne survient que lorsqu'il y avait une planification mentionnée dans la définition du service, remplaçant la planification du template.
J'ai passé l'option de rétention de la planification des check à 0 et j'ai vu la planification disparaître (N/A).
Mon serveur Nagios est situé sur une VM, j'y ai ajouté NDO.
Pour moi il s'agissait de temps CPU de vmware faussés dû à un overhead trop important (100% de CPU utilisé et 100 de mémoire en permanence).
Je me suis réellement aperçu du bug lors de l'ajout d'une 40aine de serveurs (j'en ai a peu près 400 en supervision et deux fois plus de services), je l'avait déjà vu, mais j'ai cru que c'était dû a une planification complexe (timeperiods avec des exclusions).
J'avais refait toute la planification de mes checks et je n'ai plus vu le bug jusqu'à cet ajout.
lorsque je faisait un reload, la planification restait à l'année prochaine.
Ce que j'ai fait pour que le bug disparaisse (jusqu'à sa prochaine apparition) : Déplacement de la base NDO sur un autre serveur et ajout d'un CPU au niveau de la VM : maintenant, je ne constate plus le phénomène et je n'ai plus de saturation ni mémoire, ni CPU.
Bonjour, J'ai aussi le meme problème,
Laurent | jeudi, avril 9 2009 | 16:16Bonjour,
J'ai aussi le meme problème, planification à année+1 sur certains service mais pas d'autres. J'ai effectivement ajouté ndo (en test) et c'est depuis ce temps la que c'est arrivé.
Apres suppression du ndo, idem.
Meme apres un reboot du serveur, rien n'y fait.
Solution: refaire une planification pour chaque service....
Vous avez parlé de fork... je crois que c'est dans
dams | vendredi, juillet 3 2009 | 16:41Vous avez parlé de fork... je crois que c'est dans le tuyau....
http://www.icinga.org/
Bonjour dams, Oui j'en ai même parlé sur mon blog
Cédric Temple | vendredi, juillet 3 2009 | 16:57Bonjour dams,
Oui j'en ai même parlé sur mon blog :
http://cedrictemple.net/dotclear/in...
:-)
Salut à tous, je sais que ce poste remonte un peu,
Pastaguas | mercredi, août 5 2009 | 07:17Salut à tous, je sais que ce poste remonte un peu, mais voila depuis le temps et les deux dernière release je voulais savoir si ce bug avait été corrigé.
Malheureusement (d'après mes souvenirs) j'avais testé la 3.1 la correction ne fonctionnait pas.
Je suis donc toujours en 2.12 ....
Quelqu'un a un retour sur les corrections ?
Salut à tous, J'ai eu droit aussi à ce bug en
Capi | lundi, août 17 2009 | 13:52Salut à tous,
J'ai eu droit aussi à ce bug en 3.0.6.
J'ai fais la mise à jour en 3.2.0 et oh miracle plus de bug dans l'ordonnancement.