Service checks très rares...

[stekut]

Bonjour à tous,

Mon centreon actuel (1.4.1) supervise (à l'aide de Nagios 2.9) 300 services pour 70 hôtes.

Tous mes services sont checkés toutes les 10 minutes (avec 2 essais en cas de problèmes) et mes hôtes sont checkés toutes les 30 min (avec 2 essais également).
Je compte bien désactiver le check toutes les 30 min de l'hôte mais là n'est pas la question.

Mon problème :
Il est 16h52, je regarde un service check en statut CRITICAL où je vois que le dernier contrôle a été réalisé à 15h30 (je refresh la page pour voir si le problème ne vient pas de là, cela ne change rien).
Du coup je clique sur le service et je vois que le dernier check a été (en effet) effectué à 15h30 et le prochain sera à 16h49 (alors qu'il est déjà 16h52...)
Quelqu'un connaît ce problème ??? Pourquoi attend-il 1h20 ???

Du coup je me dis "Que se passe-t-il en cas de problème d'un équipement ?" Je me connecte sur mon firewall, je bloque l'accès total depuis centreon vers une machine quelconque sous supervision à 16h20.
Je teste sur ma RedHat ou Centreon est installé (avec Nagios of course) et je tente de faire un PING et une requête SNMP. Les deux échouent bien.
J'attends alors de voir quand cela remontera dans Centreon...il est 17h00 et toujours rien !!! Pourquoi donc ? J'ai bien vérifié, tous mes services checks sont planifiés toutes les 10 minutes, ces checks auraient déjà avoir eu lieu depuis un bout de temps...

Autre problème, le check n'étant pas effectué, j'essaye de forcer un check immédiat, et on dirait qu'il n'est pas pris en compte, du moins je ne vois aucune amélioration suite à ce check immédiat (le dernier check est toujours indiqué à la même heure et le suivant aussi...)

Si quelqu'un a une idée, je suis preneur...la machine passe en prod' la semaine prochaine, si cela persiste je suis mal !

Merci à tous.

[naparuba]

Regarde si tu un as agressive host check a 1 et si tu n'a pas mis dans tes hosts un Normal Check Interval une valeur différente de zero.

[stekut]

Hello,

non mon aggressive host check est à 0 (c'est toi qui m'a d'ailleurs donné le "tips" dans un autre sujet), par contre l'intervale de mes hosts checks est à 30 minutes, c'est quand même pas ça qui entraîne mes problèmes si ?
Je ne vois pas ce qui pourrait lier les deux...par ailleurs, pourquoi au bout d'une heure j'en suis toujours à mon premier essai de check (et non pas au 2è ou 3è car du coup ça voit des problèmes mais tant que les 3 essais ne sont pas passés, pas d'envois de mails...)

[stekut]

Voici les données de performances de nagios que j'ai :

Active Service Checks:

Time Frame Checks Completed
<= 1 minute: 0 (0.0%)
<= 5 minutes: 0 (0.0%)
<= 15 minutes: 0 (0.0%)
<= 1 hour: 23 (5.9%)
Since program start: 23 (5.9%)

Metric Min. Max. Average
Check Execution Time: 0.01 sec 62.22 sec 3.900 sec
Check Latency: 0.16 sec 13131.18 sec 10029.829 sec
Percent State Change: 0.00% 24.21% 1.87%

Passive Service Checks:

Time Frame Checks Completed
<= 1 minute: 0 (0.0%)
<= 5 minutes: 0 (0.0%)
<= 15 minutes: 0 (0.0%)
<= 1 hour: 0 (0.0%)
Since program start: 0 (0.0%)

Metric Min. Max. Average
Percent State Change: 0.00% 0.00% 0.00%

Active Host Checks:

Time Frame Checks Completed
<= 1 minute: 0 (0.0%)
<= 5 minutes: 2 (2.6%)
<= 15 minutes: 4 (5.3%)
<= 1 hour: 12 (15.8%)
Since program start: 9 (11.8%)

Metric Min. Max. Average
Check Execution Time: 0.01 sec 10.02 sec 1.623 sec
Check Latency: 0.00 sec 13680.76 sec 7545.066 sec
Percent State Change: 0.00% 29.87% 4.70%

Passive Host Checks:

Time Frame Checks Completed
<= 1 minute: 0 (0.0%)
<= 5 minutes: 0 (0.0%)
<= 15 minutes: 0 (0.0%)
<= 1 hour: 0 (0.0%)
Since program start: 0 (0.0%)

Metric Min. Max. Average
Percent State Change: 0.00% 0.00% 0.00%

Je ne comprends pas pourquoi si peu de checks ont été réalisés !

[naparuba]

Hum.. ça deviens étrange en effet. Tes hosts check n'ont pas l'air d'être trop lancés, et ceux qui le sont ne dépassent pas 10s. Tu as un check de service qui dépasse les 60s on dirait. Tu as combien en max_concurent_service_check (nom de la variable approximative).

Tu peux faire un nagios -s nagios.cfg? On devrait y voir plus clair avec ça.

[stekut]

Mon max concurrent check est à 20.

Je viens juste de le passer à 50 car d'après mon Cacti, centreon ne dépasse jamais un load de 8%.

Cela n'a pas l'air d'améliorer le shmilblick !

nagios -s nagios.cfg me donne :

Nagios 2.9
Copyright (c) 1999-2007 Ethan Galstad (http://www.nagios.org)
Last Modified: 04-10-2007
License: GPL

Warning: Contact group 'EQUIPE_SUPERVISION' is not used in any host/service definitions or host/service escalations!
Projected scheduling information for host and service
checks is listed below. This information assumes that
you are going to start running Nagios with your current
config files.

HOST SCHEDULING INFORMATION
---------------------------
Total hosts: 76
Total scheduled hosts: 0
Host inter-check delay method: SMART
Average host check interval: 0.00 sec
Host inter-check delay: 0.00 sec
Max host check spread: 30 min
First scheduled check: N/A
Last scheduled check: N/A


SERVICE SCHEDULING INFORMATION
-------------------------------
Total services: 391
Total scheduled services: 391
Service inter-check delay method: SMART
Average service check interval: 600.00 sec
Inter-check delay: 1.53 sec
Interleave factor method: SMART
Average services per host: 5.14
Service interleave factor: 6
Max service check spread: 30 min
First scheduled check: Wed Feb 13 10:47:03 2008
Last scheduled check: Wed Feb 13 10:57:07 2008


CHECK PROCESSING INFORMATION
----------------------------
Service check reaper interval: 10 sec
Max concurrent service checks: 50


PERFORMANCE SUGGESTIONS
-----------------------
I have no suggestions - things look okay.

[naparuba]

300 services ce n'est pas la mort, même avec 20 il devrait être ok (si on a bien un timeout a 10 secondes pour les checks tout de même). Au pire, tu peux mettre 0 (illimité), mais bon, c'est violent.

Un moyen pour debugguer simplement que j'utilise dans ces cas là est tout simplement de faire un top sur le user nagios et de printer les commandes. Comme ça je vois en temps réel ce qui lance et ce qui repends du temps (tu vois bien comme ça les hosts check qui passent tout seul, puis après les check de service qui se lance par groupe de 10 pour rattraper le retard :) )

[stekut]

Oki, je vais tenter la chose et je te ferai un retour, merci du conseil :-)

[stekut]

Là je suis perdu, dans Nagios (page de scheduling), je vois bien que j'ai une foultitude checks programmés pendant 5minutes environ (toutes les 1-2 sec), et quand je fais un top -u nagios j'ai juste deux process nagios qui tourne, j'ai du voir passé 2-3 checks en 3 minutes et c'est tout !!! Je retourne sur la page de scheduling et rien n'a bougé, il est 11h14 et j'attends toujours ceux de 11h10...

Tiens, 11h15 dans mon top je vois un paquet de check lancés, et pouf pu rien, je retourne sur la page de scéduling, et tous les check de 11h10 on disparu, j'attends ceux prévu à 11h11...

11h19, toujours rien pour ceux de 11h11...j'attends...c'est vraiment étrange ! Je ne vois pas ce qui peut expliquer un tel comportement...

[naparuba]

Et il n'y a pas un check host qui tourne? Je n'ai jamais vu ce comportement, c'est vraiment étrange.

[stekut]

Non pas de check host.

[stekut]

Je me rappelle à présent que la personne qui a installé nagios et centreon s'y est reprise à plusieurs fois (je me dit que j'aurais peut être dû le faire moi-même !).

1è fois avec les rpm : échec
2è fois avec les tarball : erreurs donc échec
3è fois avec le script d'install d'Oreon : succès

Y aurait-il des reliquats d'installs foireuses pouvant entrainer des comportant étranges de la part de nagios ? Car là le soucis semble bien être au niveau de nagios et pas de centreon.

[naparuba]

Donc il sait qu'il doit les lancer à l'heure dites, mais il ne le fait pas, alors qu'il n'y a pas de host check en cours. Et il ne fait rien pendant ce temps là.

Tu n'as pas deux daemons qui tournent en même temps ?

[stekut]

Si, en effet j'ai deux démons, dont un est le fils du second. Ce n'est pas normal ?

ps -ef | grep nagios | grep -v grep
nagios 2966 32697 0 14:32 ? 00:00:00 /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
nagios 20416 1 0 11:27 pts/1 00:00:01 /usr/bin/perl -w /usr/local/oreon/ODS/ods
nagios 32697 1 0 13:47 ? 00:00:03 /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg

Si je redémarre, j'en ai toujours 2, un qui se lance, et le ldeuième qui se créé dans la foulée.

[stekut]

Oulà, qu'est ce que c'est que ça :

4938 nagios 19 0 0 0:00.00 0.0 0 0 0 Z sh <defunct>

Cela ne me dit rien qui vaille...

[stekut]

Un nouveau ps -ef avec toutes les infos :

nagios 3679 1 0 14:47 ? 00:00:03 /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
nagios 4362 1 0 14:48 pts/0 00:00:00 /usr/bin/perl -w /usr/local/oreon/ODS/ods
nagios 5878 3679 0 15:11 ? 00:00:00 /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
nagios 5879 5878 0 15:11 ? 00:00:00 [sh] <defunct>

un process nagios fils est créé par le maître et ce fils créé lui-même un "sh <defunct>"...après quelques recherches les quelques personnes face à la même situation observent un comportement étrange de nagios qui ne fait plus de check ou alors très rarement...
J'essaye de tuer le processus nagios fils, mais dès que je le tue il se relance... de même avec le "sh <defunct>" quand je le tue il se relance, et quand je fais la manip' sur les deux en même temps (nagios fils + sh defunct") idem.

Il faudrait trouver une solution pour que nagios ne se fork pas...

J'avance doucement...si quelqu'un à une idée, elle est toujours bienvenue !!!

[naparuba]

En fait, se forker est le comportement normal de Nagios. Par contre, je n'ai jamais rencontré le sh en defunct, je ne sais pas d'où il sot celui là, peut être un check qui par en cacaouette et qui bloque le reste.

[stekut]

J'ai passé le paramètre service_reaper_frequency à 2 (par défaut à 10).
Cela à l'air de résoudre mon problème, plein de checks sont faits, tous ceux qui sont schedulé sont exécutés quand ils le doivent, bref ça à l'air ok.
Je n'ai plus de zombie "sh <defunct>" c'est rassurant :-)

Je n'ai pas bien compris à quoi correspondait ce paramètre, mis à part que c'est lié au scheduling des checks au niveau core de nagios, c'est donc un peu de la bidouille, quelqu'un saurait m'en dire plus ?

Par ailleurs, comment déterminer la valeur optimale pour ce paramètre ???

Merci.

[-Archi-]

Il correspond à la fréquence à laquelle les résultats des checks de service sont remontés à Nagios, par contre ce n'est pas lié au fait de les exécuter ou pas :/ Au mieux ça peut influer sur les délais et la charge de Nagios mais rien de plus. 10 c'est pas mal comme valeur, 2 c'est (trop ?) faible, tu dois d'ailleurs avoir un avertissement si tu fais le test d'optimisation de Nagios lors de son relancement.

Tant mieux que ça marche, mais ça reste bizarre.

[stekut]

Le test d'optimisation ne me retourne pas d'infos là dessus, tout semble bon pour lui.
Pour moi ça a marché, je n'ai plus de process zombie "sh <defunct>", ni de processus nagios fils d'autres processus nagios.
Je n'ai que des process master nagios.

Je ne dit pas que cette variable influe directement sur le fait d'exécuter les checks, j'ai juste constaté qu'à 10 le process nagios à tendance à forker un fils qui lui même va forker un zombie comme ci le master ne répondait plus et cela entraîne le comportement décrit quelques posts plus haut.

Je viens de passer la variable à 5...voyons voir :-)

[pateretou]

Mouais, j'ai le meme genre de problème:
j'avais a peu pres 400 services a checker sur 50 hosts et une latency de fou.
J'ai commencé a enlever les checks les uns apres les autres voir si j'avais pas un pb sur un check. Puis j'ai transformé tous mes "check_centreon_ping" en check_centreon_dummy. Meme problème. Pour le coups je me retrouve plus qu'avec 40 hosts a checker pour 40 services et même problème.

J'ai commencé a me demander si j'avais pas un problème sur le serveur (bi pro quadri coeur avec 4go de ram quand meme). Le cpu depasse rarement les 4%. La ram est "tranquille" (moins de 1go). J'ai fait des tests sur le disque dur. Il monte a 90Mg/sec (SAS 10.000 tours). Puis j'ai fait des perfs de sql. Pas de surprises a ce niveau la : ca boost mémé.
Et pourtant tjrs cette latency de fous sur Nagios (entre 50 et 80s de latency!).
Je suis pas en aggressive.
J'ai joué avec le max_concurent_service_check ça ne change rien.
Je vais essayer de jouer avec le service_reaper_frequency, mais j'y crois moyen...

J'vais essayer de mettre a jour nagios avec la RC2 aussi mais bof ....

Vraiment bizzare.

[Guigui2607]

La latency ne vient peut être pas de Nagios, mais des hosts qui mettent peut être du temps à donner leur réponse à la requete de Nagios... :roll:
Tu fais des checks toutes les minutes ?

[pateretou]

Bon, en fait je pense avoir trouvé. Il semblerait que le problème viennent de la cascade de Nagios et du service-submit-check-result qui mets du temps a envoyer le message.
Je vais chercher de ce coté mais ca m'enlève un gros poids deja ...
En espérant que je puisse quand même cascader ....

[stekut]

as-tu observé dans tes process un zombie lancé par l'utilisateur nagios ? Pour ma part, c'est ce process zombie qui plantait tout et en changeant le max repear frequency je n'ai plus de process zombie (sh <defunct>).

[pateretou]

NOn, visiblement, pas de process zombie. Visiblement un pb avec le submit_check_result. Mais la le pb peut venir du nagios "master" sur lequel les infos sont envoyés et qui est bcp moins puissant.
Je vais orienter mes recherches dans ce sens.

Merci :)