Latence Nagios

[Guigui2607]

:!: Avis aux experts 'Nagios' :!:

J'ai un serveur nagios qui supervise quasiment 2000 hôtes 'Windows' (2000, 2003).
Ceci fait un total d'un peu près 14000 services à vérifier...

Les 2000 serveurs sont répartis (quasi équitablement) sur 4 serveurs 'passerelle' qui effectuent les requêtes demandées par Nagios sur les serveurs distants. (Sur ces 4 serveurs tourne NRPE).

Principe:
Nagios fait une requête NRPE sur un des 4 serveurs 'passerelle'. Ce dernier effectue la requête demandée sur le serveur distant et renvoie à nagios le résultats.

Voilà ce qui m'amène:
Depuis quelques jours, la latence atteint plusieurs centaines de secondes... :!!!:
J'ai quelques hosts qui sont down (3%)... Et dont les checks tombaient en timeout. Sinon, tout le reste fonctionne sans problème.

J'ai ajouté un service supplémentaire sur tous mes hosts pour qu'un simple ping soit effectué.
En fonction du résultat du ping, les autres checks du host ne sont pas effectués. (du coup, moins de timeout) (dépendances de services)

Mais la latence reste tout de même plus ou moins élevée.

Un nagios -s nagios.cfg ne me préconise aucune modification de la conf...

J'ai repris la conf, mais je ne vois plus quel autre paramètre à modifier.

J'en appelle donc aux 'experts' Nagios du forum qui auraient déjà eu ce genre de problème ou qui auraient des idées pour le résoudre... ou tout simplement une explication :wink:

Merci d'avance !

[naparuba]

Tu as des hosts checks de programmé? Quelle est ta version de Nagios? Tu as combien de load average sur ces 5 machines (on ne sait jamais)?

[Guigui2607]

Sur les hosts, je n'ai juste le check_host_alive...

Sur les 5 machines, une seule est en linux. Sur celle-ci, le load_average tourne autour de 1.8... (Je sais :roll: )

Sur les 4 autres qui sont sous Windows, la charge CPU ne semble pas débordée... Ils tournent autour de 2~3%

Pour le moment, je suis toujours en Nagios 2.6.

[naparuba]

Mais tu as un un "Normal Check Interval" dans la conf de tes hosts?

[Guigui2607]

Concernant les services de mes hosts:

- Le service qui fait le 'ping' est fait toutes les minutes.
- Ensuite, certains services sont fait toutes les 5mn (CPU, I/O_disk) et d'autres toutes les 10 mn (Taille_swap, espace_disk).

[naparuba]

Donc pas de agressive host check ou de vrai check host schédulé? tu as combien en max parallel checks?

Tu peux nous donner la sortie du nagios -s nagios.cfg?

Certains on eu moins de problèmes en abaissant le paramêtre reaper_frequency (genre à 2secondes).

Un bon moyen que j'utilise dans ce genre de cas, c'est de directement regarder ce qu'il lance dans les faits:
top puis Z et C et enfin u pour sélection du user nagios. Comme ça en suivant en réel ce qu'il fait, tu vois s'il fait trop de hosts check. C'est un mode debug qui ne coute pas trop cher en gros :)

[Guigui2607]

Pas d'aggressive_host_check.
max_parallel_check=0
et le service_reaper_frequency=10 :roll:


HOST SCHEDULING INFORMATION
---------------------------
Total hosts: 1913
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: 13969
Total scheduled services: 13969
Service inter-check delay method: USER-SUPPLIED VALUE
Inter-check delay: 0.05 sec
Interleave factor method: SMART
Average services per host: 7.30
Service interleave factor: 8
Max service check spread: 30 min
First scheduled check: Mon May 19 16:06:36 2008
Last scheduled check: Mon May 19 16:18:15 2008


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


PERFORMANCE SUGGESTIONS
-----------------------
I have no suggestions - things look okay.
Voilà, ce que ça donne...

[naparuba]

Tu peux essayer de mettre le "Service inter-check delay method" en smart. Car disons que tu as que des check à 10minutes (on simplifie au meilleur cas):
14000*0.05=700s pour l'ordonancement de tous tes checks. Soit plus que les 10 minutes. Je pense que tu peux abaisser cet intervale ou carément le laisser gérer ce seuil en smart.

Tu peux donner ta conf niveau nagios.cfg sur ces points?

Courage, on va l'avoir cette latence :)

[Guigui2607]

service_inter_check_delay_method=0.05
max_service_check_spread=30
service_interleave_factor=s
host_inter_check_delay_method=s
max_host_check_spread=30
max_concurrent_checks=0
service_reaper_frequency=10
auto_reschedule_checks=0
auto_rescheduling_interval=30
auto_rescheduling_window=180
sleep_time=0.05
service_check_timeout=60
host_check_timeout=30
retain_state_information=1
retention_update_interval=60
use_retained_program_state=1
use_retained_scheduling_info=0
interval_length=60
use_aggressive_host_checking=0
execute_service_checks=1
accept_passive_service_checks=1
execute_host_checks=1
accept_passive_host_checks=1
aggregate_status_updates=1
status_update_interval=60

Je pense avoir mis l'essentiel...

Courage, on va l'avoir cette latence
Merci :wink:

[naparuba]

Tentes avec service_inter_check_delay_method à s cela devrait aider. Si tu n'aimes pas le s, tentes avec 0.01

Petite question : pourquoi avoir mis le sleep_time à 0.05? (j'ai du mal avec cette variable par rapport au service_inter_check_delay_method donc si tu sais à quoi elle sert précisément je suis preneur :) ).

[Guigui2607]

Je vais tester la valeur 's' pour voir ce que ça donne... C'est le serveur de prod :roll: Donc pas évident... Je vais essayer de voir quand je pourrai faire la modif...
Concernant le sleep_time à 0.05... c'est un 'reste' d'un précédent test (qui n'a rien donné). Désolé :?

Dès que j'ai fait modif, je te tiens au courant :wink:

Merci encore pour ton aide !

[naparuba]

De rien. Je pense que ca devrait aller mieux après.

[Guigui2607]

Bon, j'attends toujours le feu vert pour faire la modif...
En attendant, je continue à cherche d'autre(s) éventuelle(s) cause(s)...
J'ai plusieurs questions qui me viennent:

- Nagios enregistre les états de tous les hosts et services lorsqu'il s'arrête. Est-ce que le fait que Nagios redémarre, il se base sur les états qu'il a enregistrés précédemment pour calculer sa latence.

- Comme je l'ai décrit plus haut, j'ai mis en place des dépendances:
J'ai fait un service qui fait un ping sur tous les hosts. Si ce ping est bon, Nagios fait les autres requêtes sur cet host. Sinon il les zappe.
Par contre, Nagios envoie les requêtes "à la volée"... Il est donc possible qu'une requête x ou y soit envoyée avant d'avoir fait le ping sur le host... Donc les requêtes x ou y tombent en "timeout" et la latence commence à augmenter...
D'où la question suivante: Peut-on mettre des priorités sur les checks pour que les pings soient faits avant les requêtes x ou y ? :roll:

[naparuba]

Pour le premier point je ne sais pas mais je doute fortement qu'il l'utilise, car cette valeur serait bien élevée lors d'un redémarrage après une longue pause. C'est à tester.

Pour le second point c'est en effet un problème et je ne connais pas de solutions à ça. Si quelqu'un à une solution pour la gestion des dépendances nous sommes preneurs :)
J'utilise personellement beaucoup les relations parents/enfants et j'ai modifiés mes checks pour qu'en cas de timeout sur les éléments distants, le service passe en unknown (pour les tests systèmes, pour les tests applicatifs cela dépends des cas). comme ca je n'ai que l'alerte de host down/up et pas 10000 messages.

[Guigui2607]

Ok :( Merci pour toutes ces précieuses précisions naparuba :wink: Ça confirme ce que je pensais...
[...]comme ca je n'ai que l'alerte de host down/up et pas 10000 messages.
Tu supervises beaucoup d'Hosts / Services ?

[Ludo31]

Bonjour,
pour ceci
- Comme je l'ai décrit plus haut, j'ai mis en place des dépendances:
J'ai fait un service qui fait un ping sur tous les hosts. Si ce ping est bon, Nagios fait les autres requêtes sur cet host. Sinon il les zappe.
Par contre, Nagios envoie les requêtes "à la volée"... Il est donc possible qu'une requête x ou y soit envoyée avant d'avoir fait le ping sur le host... Donc les requêtes x ou y tombent en "timeout" et la latence commence à augmenter...

Il n'ya pas besoin de mettre en place ses dependances car quand un service remontent un etat autre qu'ok il vérifie que l'hote est up ou non, ce qui veut dire que si ton hote est down ou unreacheable tous les services qui sont derriere ne seront plus checker jusqu'au retablissement de l'hote!! cette dépendance est pour moi inutile :D

[naparuba]

Tu supervises beaucoup d'Hosts / Services ?

C'est plutôt raisonnable:
400 hosts (75% serveurs, 25% élément de réseaux) et 4000 services.

[Guigui2607]

@ Ludo31: Dans mon cas, en prod, avec Nagios 2.6, il continuait à faire les checks sur les hosts down...

@ Naparuba: Effectivement raisonnable :wink: Je poursuis mon enquête :|

Merci en tout cas pour vos infos...

[naparuba]

Ludo31: pareil pour moi en 2.5, j'ai du patché mon nagios pour qu'il ne m'embète plus dans ces cas là.

[Ludo31]

Moi j'ai la 2.10 et j'ai pas de pb la dessus
Host DOWN ou UNREACHEABLE => Arret des checks de services

[naparuba]

Ca a du arriver entre ces versions, je vais essayer de jeter un coup d'oeil aux changelogs car je ne connais pas de paramètres influant sur ça.

[Guigui2607]

J'ai rien vu de spécial sur les changelogs... Je vais quand même essayer de reproduire tout ça avec une version plus récente sur un serveur de test... On verra bien :roll:

[Guigui2607]

Je reviens 2 secondes sur ton post Ludo31...
Y'a t'il une configuration spécifique sur tes hosts pour que Nagios ne fasse plus les checks sur les services du host qui est down ? Ou un paramètre que j'aurais zappé ?

[Guigui2607]

J'ai remis le nez dans la doc (RTFM :mad: ): http://nagios.sourceforge.net/docs/2_0/checkscheduling.html#host_checks

Hé hé, normalement Nagios le fait tout seul (merci Ludo31 :wink: )

Cependant: Also of note - when Nagios is check the status of a host, it holds off on doing anything else (executing new service checks, processing other service check results, etc). This can slow things down a bit and cause pending service checks to be delayed for a while, but it is necessary to determine the status of the host before Nagios can take any further action on the service(s) that are having problems.

A priori, en lien avec la valeur max_attempts de la définition des hosts :roll:

[Ludo31]

Moi je check les hosts toutes les 10 minutes, mais je pense pas qu'il y est une maniére de configurer l'hote. Donc que l'on mette 0 pour checker à la demande ou toutes les 10 minutes cela revient au même!:)

[Guigui2607]

Actuellement, il n'y a qu'un check_host_alive sur mes hosts.
Et je n'ai pas mis de check_interval sur mes hosts.
Ils ont un max_check_attempts à 10...

Est-ce qu'en passant le max_check_attempts à 1 pourrait aider à ne pas continuer à vérifier les services sur mes hosts down ?
Et du coup faire baisser ma latence ?

[Ludo31]

Non je pense pas que ca t'aide puisque le max_check_attempts sert à déterminer le moment ou ton check passera à l'état hard.
Et comme nagios va toujours aller vérifier l'état de ton hote pour surveiller si il est remonter ou pas ca ne changera rien à ton pb de latence.

Par contre ce qui peut arranger si tu ne l'a pas fait c'est de vérifier la commande check_host_alive pour savoir combien de paquets icmp elle envoie?? personnellement je mis le nombre de paquets envoyés à 1 pour accélerer le processus de check

[Guigui2607]

Il est aussi à 1... :roll: :|

[naparuba]

Et question timeout de la commande de ping?

[Guigui2607]

Je n'ai pas mis de timeout sur mon ping, juste l'envoi d'un seul paquet:
define command{
command_name check-host-alive
command_line $USER1$/check_ping -H $HOSTADDRESS$ -w 3000.0,80% -c 5000.0,100% -p 1
}
Par défaut le timeout du ping est à 10.

[naparuba]

Tu peux tenter un timeout plus petit, car là pendant 10 secondes tu n'auras aucuns checks de fait. J'ai touours considérés des machines ne répondant pas en moins de 3 secondes comme non disponible, car tente d'atteindre un programme dessus, ca sera inutilisable. C'est équivalent à "ne réponds pas au réseau" :)

[Guigui2607]

Effectivement, je peux tenter de voir ça aussi... Merci :wink:

[Guigui2607]

J'ai testé le timeout en ligne de commande:
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 10
CRITICAL - Plugin timed out after 10 seconds
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 9
CRITICAL - Plugin timed out after 9 seconds
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 8
CRITICAL - Plugin timed out after 8 seconds
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 7
CRITICAL - Plugin timed out after 7 seconds
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 6
CRITICAL - Plugin timed out after 6 seconds
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 5
CRITICAL - Plugin timed out after 6 seconds
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 4
CRITICAL - Plugin timed out after 6 seconds
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 3
CRITICAL - Plugin timed out after 6 seconds
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 2
CRITICAL - Plugin timed out after 6 seconds
# ./check_ping -H HOSTNAME -w 3000.0,80% -c 5000.0,100% -p 1 -t 1
CRITICAL - Plugin timed out after 6 seconds
Est-ce que ça veut dire que je ne peux pas descendre le timeout en dessous de 6s ? J'ai testé sur un autre serveur Nagios de test, même combat, on ne peut pas descendre sous 6s... :roll:

[naparuba]

Il faut croire. Que donne un changement de 3000 en 2500 dans le w?

[Guigui2607]

Effectivement Naparuba :wink: il faut jouer sur les valeurs -w et -c pour pouvoir descendre la valeur du timeout. Merci, je vais voir ce que je peux faire maintenant avec tout ça... Thx !

[naparuba]

Je me souviens avoir eu ce genre de problèmes avec ce plugin ;)

D'ailleurs j'ai complètement arrété les tests par ping au final (en matière de systèmes) en préférant la vérification d'un port TCP (22 sur linux, 139 sur windows, 23 pour les vieux équipements réseaux) car ce n'est pas courant de voir l'icmp passer les firewalls par exemple, alors que les ports d'administration oui :)

[Guigui2607]

:cool: bien vu !! :wink:
Je vais déjà voir ce que donne le changement des -w et -c ainsi que le timeout...
Encore merci pour toutes ces précisions !

[Guigui2607]

Bon, j'ai pu faire la modif ce matin :cool:
J'ai quand même l'impression que nagios garde en mémoire après un reboot les valeurs qui sont affichées dans l'encart "Monitoring Performance" en haut à droite de la page Tactical Overview.
J'ai toujours d'affiché, après le reboot, la valeur max que j'avais avant la modif...
Cependant elle baisse tout doucement depuis ¼h.

Pour le moment, ça fait ¼h et la latence moyenne baisse tranquillement et la latence min ne grimpe pas (trop)...

J'ai en profité pour remettre la valeur de "service_inter_check_delay_method" à "s".

Je vous tiens au courant...

[naparuba]

Cool :)

Cest bon à savoir qu'il utilise les anciens résultats pour la latence. Peu être qu'un nagiostat fait un autre calcul, tu pourrais essayer.

[Guigui2607]

Pas glop, pas glop :sad:

Ça ne donne rien de mieux...

Un 'nagiostat -c' donne ceci
CURRENT STATUS DATA
----------------------------------------------------
Status File: /var/nagios/status.dat
Status File Age: 0d 0h 0m 22s
Status File Version: 2.6

Program Running Time: 0d 1h 1m 56s

Total Services: 13720
Services Checked: 13720
Services Scheduled: 13720
Active Service Checks: 13720
Passive Service Checks: 0
Total Service State Change: 0.000 / 30.790 / 0.176 %
Active Service Latency: 766.365 / 863.674 / 810.928 sec
Active Service Execution Time: 0.066 / 60.601 / 2.293 sec
Active Service State Change: 0.000 / 30.790 / 0.176 %
Active Services Last 1/5/15/60 min: 470 / 3295 / 10345 / 13482
Passive Service State Change: 0.000 / 0.000 / 0.000 %
Passive Services Last 1/5/15/60 min: 0 / 0 / 0 / 0
Services Ok/Warn/Unk/Crit: 13322 / 24 / 140 / 234
Services Flapping: 0
Services In Downtime: 0

Total Hosts: 1869
Hosts Checked: 1869
Hosts Scheduled: 0
Active Host Checks: 1869
Passive Host Checks: 0
Total Host State Change: 0.000 / 4.800 / 0.005 %
Active Host Latency: 0.000 / 0.000 / 0.000 sec
Active Host Execution Time: 0.065 / 10.263 / 0.372 sec
Active Host State Change: 0.000 / 4.800 / 0.005 %
Active Hosts Last 1/5/15/60 min: 9 / 59 / 127 / 192
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 1827 / 42 / 0
Hosts Flapping: 0
Hosts In Downtime: 0

Un 'nagios -s' donne ceci:
HOST SCHEDULING INFORMATION
---------------------------
Total hosts: 1869
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: 13720
Total scheduled services: 13720
Service inter-check delay method: SMART
Average service check interval: 307.66 sec
Inter-check delay: 0.02 sec
Interleave factor method: SMART
Average services per host: 7.34
Service interleave factor: 8
Max service check spread: 30 min
First scheduled check: Wed May 28 10:34:24 2008
Last scheduled check: Wed May 28 10:39:32 2008


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


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

Dans mon nagios.cfg, j'ai la variable 'use_retained_scheduling_info' à '1'...
Dans la doc: mettre à 0 si grand nombre de services :roll:

Je peut-être voir dans ce sens :???:

[naparuba]

Dis nous ce que ca donne, la gestion de la latence est un vrai dilemme et toutes les pistes sont bonnes à prendre :)

[Guigui2607]

Dans mon nagios.cfg, j'ai la variable 'use_retained_scheduling_info' à '1'...
Dans la doc: mettre à 0 si grand nombre de services :roll:

J'ai écrit des bêtises, cette variable est déjà à 0...
C'est dans la doc qu'elle est à 1 par défaut... ^^

Je suis en train de relire toute la doc (surtout la partie nagios.cfg) pour trouver une autre piste... (:evil: RTFM :evil:)

Pour le moment, rien de bien intéressant. :cry:

[naparuba]

Courage, relire la doc peut toujours servir, même pour plus tard ;)

Ta latence ne descends plus alors?

[Guigui2607]

Non, elle a commencé à quelques dixièmes de secondes et s'est stabilisée 30mn.
:arrow: use_retained_scheduling_info=0 + max_service_check_spread=30 + max_host_check_spread=30

Ensuite après la première ½h, la latence min a augmenté doucement mais sûrement pour atteindre les valeurs affichées avec le nagiostat -c :sad:

Là, la modif a été faite, il y a 2h, et ma latence stagne toujours à des sommets...

Je me demande de + en + si mon nagios ne supervise pas trop de serveurs / services...
Je n'ai jamais trouvé de limites bien définies quant à la quantité des serveurs / services maximum à superviser.

Est-ce que vu le nombre de serveurs / services, il n'aurait pas été plus judicieux d'utiliser NSCA plutôt que NRPE :roll: J'ai toujours été habitué à utiliser NRPE jusqu'à maintenant.

[naparuba]

Pour la valeur max tu prends la moyenne du temps d'exécution des services multipliés par le nombre de service, tu ajoutes le temps de timeout pour tes checks hosts (non paralélisés en nagios2) multiplifés par le nombre moyen de host down et tu as le temps qu'il te faut pour faire une passe de vérif. Ensutie Ca va dépendre en combien de temps doit se faire cette passe (toutes les 5minutes, 1/4 d'heure etc etc). A part le problème des host checks normalement c'est assez simple à voir.

[Guigui2607]

Bon, bah c'est pas gagné d'avance...
La latence ne daigne plus redescendre. Elle reste haut perchée :sad:

Je ne vois plus d'autres paramètres à modifier pour essayer d'optimiser tout ça.
C'est pour cela que je me pose la question du NSCA plutôt que NRPE...

Ou alors mon Nagios est trop chargé :???:

[naparuba]

On le verrais avec un load average très élevé. Tu avais un paramètre à 0.05 avant "s" (smart). Tu peux tenter un 0.01 mais bon le smart c'était bien.

Pour les host checks, tu en avait eu 9 dans la dernière minute sur ton nagiostat, suivant le temps de timeout ça peut faire booster la latence mais le temps d'excécution moyen de tes hosts check à l'air tranquille (0.3s). Tu as mis combien en timeout sur tes hosts check a peu près?

[Guigui2607]

J'ai mis un timeout à 4s pour le ping de la commande check_host_alive.

A moins que tu parles de la valeur host_check_timeout du fichier nagios.cfg qui est à 30s...

[naparuba]

Non non c'est bien ça. De toute manière on a vu sur le nagiostat qu'il n'arrive jamais aux 30s.

Nagios3 pourrait t'aider, mais bon, c'est violent comme méthode, surtout que c'est déjà en Prod....

[Guigui2607]

Nagios v3 pourrait améliorer les performances ?

D'après toi, quasiment 2000 serveurs et presque 14000 services, ça ne te paraît pas "trop"?
Il est vrai qu'au départ, on ne pensait pas qu'on le chargerait autant...

[naparuba]

Nagios3 améliore bien les hcoses de ce côté et surtout le point principal à mon goût: les host check sont parallélisés avec les services checks.

Tu peux me redonner un nagiostat? Je vais tenter de calculer ce que tu perd en temps à cause des host checks.

[Guigui2607]

Voilà le nagiostat de ce matin:
CURRENT STATUS DATA
----------------------------------------------------
Status File: /var/nagios/status.dat
Status File Age: 0d 0h 0m 38s
Status File Version: 2.6

Program Running Time: 0d 23h 17m 19s

Total Services: 13720
Services Checked: 13720
Services Scheduled: 13720
Active Service Checks: 13720
Passive Service Checks: 0
Total Service State Change: 0.000 / 30.790 / 0.158 %
Active Service Latency: 794.075 / 942.777 / 866.812 sec
Active Service Execution Time: 0.066 / 60.601 / 2.164 sec
Active Service State Change: 0.000 / 30.790 / 0.158 %
Active Services Last 1/5/15/60 min: 211 / 3351 / 10062 / 13492
Passive Service State Change: 0.000 / 0.000 / 0.000 %
Passive Services Last 1/5/15/60 min: 0 / 0 / 0 / 0
Services Ok/Warn/Unk/Crit: 13321 / 26 / 146 / 227
Services Flapping: 0
Services In Downtime: 0

Total Hosts: 1869
Hosts Checked: 1869
Hosts Scheduled: 0
Active Host Checks: 1869
Passive Host Checks: 0
Total Host State Change: 0.000 / 12.370 / 0.051 %
Active Host Latency: 0.000 / 0.000 / 0.000 sec
Active Host Execution Time: 0.065 / 10.263 / 0.357 sec
Active Host State Change: 0.000 / 12.370 / 0.051 %
Active Hosts Last 1/5/15/60 min: 0 / 51 / 110 / 192
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 1826 / 43 / 0
Hosts Flapping: 0
Hosts In Downtime: 0
Voilà...

Je vais peut être me pencher plus rapidement sur la v3... J'attendais que la v2 de Centreon soit sortie "pour d'une pierre, deux coups" :wink:

[naparuba]

Côté host check ça à l'air d'aller, car avec une 10aine par minute mais en 0.3s ca ne fait pas bien lourd.

Mais tu as un temps moyen de check de services de 2s, peut être à cause des timeout: 60s. Regardes s'il est possible de les baisser. Mais bon normalement avec un nombre illimité de check en parallèle ca ne devrait pas poser autant de problèmes. Peut être qu'on a un mix des deux: pour faire un host chck, Nagios attend que tous les services checks soient finis, lance son host check puis relance en parallèle au plus vite ce qu'il faut. Le problème c'est qu'avec des timeout de service a 60s, pendant 60s il ne va pas lancer de nouveaux services checks. Bref, on a toujours un problème avec cette non parallélisation. Tentes de diminuer les timeout de service checks, (de toute manière si ca ne réponds pas assez vite, autant que c ne réponde pas...). Mets 10s et regarde ce que ca donne. On tiens peu être le bon bout.

[Guigui2607]

Ok, encore merci pour ton analyse :wink:
C'est toujours mieux d'avoir un (ou des) avis extérieur sur la situation.

Je vais creuser dans cette direction. Je te tiens au courant de l'évolution.

Merci beaucoup !

[naparuba]

De rien et bon courage :)

Pour Nagios3 je vais tenter sérieusement car il apporte des facilités de configuration assez sympas ;) (question perf avec 4000 services j'ai de la marge :p )

[Guigui2607]

Bon, j'ai épluché le fichier retention.***

J'ai fait un petit point de ce qu'il se passe...

Tps Exec° | Nbre répondants dans un délai
< à 60 s -> 13681 (Soit 99,71 %)
< à 50 s -> 13679 (Soit 99,70 %)
< à 40 s -> 13551 (Soit 98,76 %)
< à 30 s -> 13547 (Soit 98,73 %)
< à 20 s -> 13542 (Soit 98,70 %)
< à 10 s -> 13507 (Soit 98,44 %)
< à 9 s --> 13493 (Soit 98,34 %)
< à 8 s --> 13469 (Soit 98,17 %)
< à 7 s --> 13449 (Soit 98,02 %)
< à 6 s --> 13416 (Soit 97,78 %)
< à 5 s --> 13061 (Soit 95,19 %)
< à 4 s --> 12017 (Soit 87,58 %)
< à 3 s --> 11685 (Soit 85,16 %)
< à 2 s --> 10413 (Soit 75,89 %)
< à 1 s --> 7271 (Soit 52,99 %)
< à 0.5s -> 129 (Soit 0,94 %)

Reste à choisir la meilleure valeur pour avoir un timeout potable en ne considérant pas trop de services 'Critical' (timeout) qui auraient pu répondre en un peu plus de temps...
20s ou 10s sembleraient pas trop mal... ('perte' entre 1 et 1.5 % :oops:)

Je vais voir ce que je peux faire :roll:

Je te tiens au courant et encore merci :wink:

[naparuba]

Joli :)

Oui 10s c'est pas mal.

[vcarp]

Bonjour,

je me retrouve partiellement dans la description du problème commenté ici.
La situation:
Nagios 2.10, 1692 équipements, 9370 services, actifs comme passifs (traps).
J'ai un temps de latence désastreux malgré le petit nombre de serveurs qui ne ping pas. De plus, ayant lu le thread, j'ai baissé le timeout de tous mes pings sans que celà change grand chose. Je suis sûr que j'ai oublié un paramètre dans un coin. Merci de votre aide.

Je joins le résultat d'un nagiostats + résultat de nagios -s + extrait nagios.cfg

Nagios Stats 2.10
Copyright (c) 2003-2007 Ethan Galstad (www.nagios.org)
Last Modified: 10-21-2007
License: GPL

CURRENT STATUS DATA
----------------------------------------------------
Status File: /var/opt/nagios/var/status/status.log
Status File Age: 0d 0h 0m 18s
Status File Version: 2.10

Program Running Time: 0d 2h 27m 19s
Nagios PID: 12236
Used/High/Total Command Buffers: 0 / 116 / 4096
Used/High/Total Check Result Buffers: 15 / 74 / 4096

Total Services: 9370
Services Checked: 8500
Services Scheduled: 8446
Active Service Checks: 9316
Passive Service Checks: 54
Total Service State Change: 0.000 / 100.000 / 0.368 %
Active Service Latency: 0.000 / 502.092 / 441.147 sec
Active Service Execution Time: 0.000 / 30.073 / 0.710 sec
Active Service State Change: 0.000 / 80.260 / 0.132 %
Active Services Last 1/5/15/60 min: 378 / 3105 / 8384 / 8444
Passive Service State Change: 0.000 / 100.000 / 41.085 %
Passive Services Last 1/5/15/60 min: 1 / 2 / 5 / 10
Services Ok/Warn/Unk/Crit: 9052 / 107 / 46 / 165
Services Flapping: 0
Services In Downtime: 0

Total Hosts: 1692
Hosts Checked: 1692
Hosts Scheduled: 0
Active Host Checks: 1692
Passive Host Checks: 0
Total Host State Change: 0.000 / 9.740 / 0.026 %
Active Host Latency: 0.000 / 943.885 / 283.328 sec
Active Host Execution Time: 0.074 / 10.065 / 0.173 sec
Active Host State Change: 0.000 / 9.740 / 0.026 %
Active Hosts Last 1/5/15/60 min: 23 / 91 / 184 / 228
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 1679 / 13 / 0
Hosts Flapping: 0
Hosts In Downtime: 0

nagios -s
HOST SCHEDULING INFORMATION
---------------------------
Total hosts: 1692
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: 20 min
First scheduled check: N/A
Last scheduled check: N/A


SERVICE SCHEDULING INFORMATION
-------------------------------
Total services: 9370
Total scheduled services: 8443
Service inter-check delay method: SMART
Average service check interval: 252.00 sec
Inter-check delay: 0.03 sec
Interleave factor method: SMART
Average services per host: 5.54
Service interleave factor: 5
Max service check spread: 4 min
First scheduled check: Fri Jun 6 14:01:25 2008
Last scheduled check: Fri Jun 6 14:05:25 2008


CHECK PROCESSING INFORMATION
----------------------------
Service check reaper interval: 5 sec
Max concurrent service checks: 1200


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

nagios.cfg
[...]
aggregate_status_updates=1
status_update_interval=30
[...]
sleep_time=1
service_inter_check_delay_method=s
host_inter_check_delay_method=s
service_interleave_factor=s
max_concurrent_checks=1200
max_service_check_spread=4
max_host_check_spread=20
service_reaper_frequency=5
interval_length=60
use_agressive_host_checking=0
enable_flap_detection=0
low_service_flap_threshold=25.0
high_service_flap_threshold=50.0
low_host_flap_threshold=25.0
high_host_flap_threshold=50.0
soft_state_dependencies=0
service_check_timeout=30
host_check_timeout=10
event_handler_timeout=30
notification_timeout=60
ocsp_timeout=1
perfdata_timeout=5
obsess_over_services=0
obsess_over_hosts=0
process_performance_data=0
check_for_orphaned_services=1
check_service_freshness=0
[...]

...

[Guigui2607]

Ahhhhh, je me sens moins seul d'un coup :mrgreen:
Bon, à première vue, rien ne me saute aux yeux :roll:
Perso, j'attends le feu vert pour faire la modif du service_check_timeout sur le serveur de prod :???:

[naparuba]

Un peu pareil, je ne vois rien qui cloche.

[vcarp]

Ce n'est pas trop pour me rassurer.

Quand je fais un top, je n'ai pas l'impression qu'il y ait beaucoup de check en parallèle.
Pour donner quelques billes supplémentaires, le serveur est un quadri Xéon à 3,33 GHz, 4Go de mémoire.
Nagios ne consomme que rarement plus de 23% de CPU. La majorité des checks sont écrits en perl avec un interpréteur intégré.

[vcarp]

Sans vouloir crier victoire, j'ai réussi personnellement à réduire la latence, passant de 9/10 minutes à 0/2 minutes.
Il faut aller regarder le nombre de fichiers que l'utilisateur nagios (ou celui qui lance la process nagios) a le droit d'ouvrir simultanément (ulimit -n). Il faut que ce nombre soit suffisamment important pour que nagios n'ait pas à attendre la fermeture des précédents pour lancer de nouvelles tâches.

Dans mon cas, je suis passé de 1024 à 2048 et envisage déjà de passer à 4096 pour voir venir.
Une autre expérience serait la bienvenue pour confirmer/infirmer cette assertion.

[naparuba]

Très jolie solution.

[Guigui2607]

Pour ma part, sur mon serveur, la commande 'ulimit -a' me revoit:
open files (-n) 65535
:roll: Je ne pense pas que dans mon cas ça pourrait changer quelque chose :sad:

Pour le moment, j'ai une latence de 5~6 minutes...
J'attends toujours le feu vert des gens de la Prod pour modifier la valeur du service_check_timeout... En espérant que ça changera quelque-chose :roll:

[naparuba]

Avec le user nagios?

Petite question vcarp: comment as tu trouvé ça?

[Guigui2607]

Bon, la modification de la valeur du timeout a été faite hier soir.
Ce matin, aucune évolution, j'ai toujours une latence de 6~7 min. :cry:
Je ne vois plus d'autre paramètre à modifier pour améliorer tout ça :roll:

Je commence réellement à penser que mon Nagios est trop 'chargé' [~1900 hosts / ~12000 services] :-?

[naparuba]

C'est quoi le load average de ta machine de prod déjà?

Tu peux nous redonner un nagiostat?

Tu as la solution du passage en v3 (il est en phase de qualif chez moi) mais c'est consommateur en temps pour les tests et il faut voir si c'est applicable dans ton cas.

Sinon tu peux tenter de bypasser tout problème avec les hosts, en mettant un service représentant l'état de la machine et de laisser les host check en dummy. Mais bon, c'est moins joli.

[Guigui2607]

Un top me donne:
top - 08:09:21 up 391 days, 15:17, 3 users, load average: 2.22, 2.15, 2.10
Tasks: 170 total, 3 running, 167 sleeping, 0 stopped, 0 zombie
Cpu(s): 24.7% us, 24.1% sy, 0.1% ni, 49.6% id, 1.5% wa, 0.0% hi, 0.0% si
Mem: 4149216k total, 699724k used, 3449492k free, 4004k buffers
Swap: 2064376k total, 101140k used, 1963236k free, 72148k cached

Un nagiostats -c nagios.cfg donne:
CURRENT STATUS DATA
----------------------------------------------------
Status File: /var/nagios/status.dat
Status File Age: 0d 0h 0m 25s
Status File Version: 2.6

Program Running Time: 0d 14h 12m 42s

Total Services: 11851
Services Checked: 11851
Services Scheduled: 11851
Active Service Checks: 11851
Passive Service Checks: 0
Total Service State Change: 0.000 / 17.370 / 0.170 %
Active Service Latency: 338.523 / 432.344 / 382.605 sec
Active Service Execution Time: 0.066 / 60.601 / 2.908 sec
Active Service State Change: 0.000 / 17.370 / 0.170 %
Active Services Last 1/5/15/60 min: 578 / 4841 / 11311 / 11514
Passive Service State Change: 0.000 / 0.000 / 0.000 %
Passive Services Last 1/5/15/60 min: 0 / 0 / 0 / 0
Services Ok/Warn/Unk/Crit: 11455 / 25 / 151 / 220
Services Flapping: 0
Services In Downtime: 0

Total Hosts: 1869
Hosts Checked: 1869
Hosts Scheduled: 0
Active Host Checks: 1869
Passive Host Checks: 0
Total Host State Change: 0.000 / 11.580 / 0.065 %
Active Host Latency: 0.000 / 0.000 / 0.000 sec
Active Host Execution Time: 0.062 / 10.263 / 0.304 sec
Active Host State Change: 0.000 / 11.580 / 0.065 %
Active Hosts Last 1/5/15/60 min: 3 / 60 / 172 / 201
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 1817 / 52 / 0
Hosts Flapping: 0
Hosts In Downtime: 0
Un nagios -s nagios.cfg me donne:
HOST SCHEDULING INFORMATION
---------------------------
Total hosts: 1869
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: 11851
Total scheduled services: 11851
Service inter-check delay method: SMART
Average service check interval: 346.72 sec
Inter-check delay: 0.03 sec
Interleave factor method: SMART
Average services per host: 6.34
Service interleave factor: 7
Max service check spread: 30 min
First scheduled check: Wed Jun 11 08:14:17 2008
Last scheduled check: Wed Jun 11 08:20:04 2008


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


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

Passer en V3 :roll: j'y pense... Mais comme tu le souligne, ça risque de prendre pas mal de temps...

[naparuba]

Tu as combien de CPU sur la machine? Tu as pas mal de temps en %sys. Tu peux nous donner le résultat d'un iostat -kx 10 2 ?

[Guigui2607]

Il y a 1 CPU (2,8 GHz) avec 4 Go de RAM et 2 disques de 70 Go RAID1.

Voilà ce que donne la commande iostat -kx 10 2
Linux 2.6.9-42.ELsmp (nagios) 06/11/2008

avg-cpu: %user %nice %sys %iowait %idle
24.73 0.08 24.12 1.46 49.62

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.43 62.35 0.43 7.97 8.58 24.53 4.29 12.27 3.94 0.12 14.62 5.83 4.90
dm-0 0.00 0.00 0.03 3.19 0.51 25.50 0.25 12.75 8.08 0.06 18.83 1.96 0.63
dm-1 0.00 0.00 0.01 0.18 0.02 0.36 0.01 0.18 2.04 0.01 27.39 7.86 0.15
dm-2 0.00 0.00 0.00 0.02 0.02 0.16 0.01 0.08 8.56 0.03 1243.60 0.37 0.00
dm-3 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.00 2.03 0.00 5.13 0.69 0.00
dm-4 0.00 0.00 0.00 0.23 0.01 1.82 0.01 0.91 8.03 0.02 79.48 5.89 0.13
dm-5 0.00 0.00 0.00 0.00 0.02 0.00 0.01 0.00 8.01 0.00 5.86 1.58 0.00
dm-6 0.00 0.00 0.10 2.96 1.63 23.70 0.82 11.85 8.27 0.06 21.09 2.14 0.66
dm-7 0.00 0.00 0.18 55.70 3.92 62.14 1.96 31.07 1.18 0.09 1.64 0.52 2.93
dm-8 0.00 0.00 0.14 3.03 1.12 24.22 0.56 12.11 8.00 0.11 34.19 0.33 0.10
dm-9 0.00 0.00 0.00 0.01 0.03 0.01 0.02 0.01 6.37 0.00 674.91 1.84 0.00
dm-10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.58 0.00 58.41 2.81 0.00
dm-11 0.00 0.00 0.08 0.01 0.17 0.03 0.08 0.01 2.02 0.01 100.56 0.07 0.00
dm-12 0.00 0.00 0.03 2.35 0.28 4.71 0.14 2.35 2.09 0.04 14.75 2.91 0.69
dm-13 0.00 0.00 0.00 0.21 0.04 0.42 0.02 0.21 2.18 0.00 20.82 10.01 0.21
dm-14 0.00 0.00 0.24 1.35 0.56 2.70 0.28 1.35 2.06 0.02 14.84 6.34 1.00
dm-17 0.00 0.00 0.01 0.00 0.04 0.01 0.02 0.01 8.00 0.00 212.04 0.40 0.00
dm-21 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.00 2.56 0.00 20.05 0.35 0.00
dm-15 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.00 2.52 0.00 23.36 0.94 0.00
dm-16 0.00 0.00 0.01 0.00 0.05 0.00 0.02 0.00 4.67 0.00 77.69 0.57 0.00
dm-18 0.00 0.00 0.00 0.69 0.03 5.56 0.02 2.78 8.00 0.01 15.18 3.45 0.24
dm-19 0.00 0.00 0.05 0.31 0.11 0.61 0.06 0.31 2.04 0.01 35.88 7.93 0.28
dm-20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 6.72 0.00 154.69 1.12 0.00

avg-cpu: %user %nice %sys %iowait %idle
36.35 0.05 37.45 0.50 25.65

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 8.70 0.20 3.40 1.60 78.80 0.80 39.40 22.33 0.03 9.56 7.67 2.76
dm-0 0.00 0.00 0.10 3.00 0.80 24.00 0.40 12.00 8.00 0.04 13.32 1.61 0.50
dm-1 0.00 0.00 0.00 0.10 0.00 0.20 0.00 0.10 2.00 0.00 10.00 10.00 0.10
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-6 0.00 0.00 0.10 1.80 0.80 14.40 0.40 7.20 8.00 0.02 8.95 1.37 0.26
dm-7 0.00 0.00 0.00 0.50 0.00 4.00 0.00 2.00 8.00 0.01 19.80 11.00 0.55
dm-8 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-9 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-11 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-12 0.00 0.00 0.00 0.70 0.00 1.40 0.00 0.70 2.00 0.01 7.57 4.00 0.28
dm-13 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-14 0.00 0.00 0.00 1.30 0.00 2.60 0.00 1.30 2.00 0.01 6.85 2.00 0.26
dm-17 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-21 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-15 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-16 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-18 0.00 0.00 0.00 3.80 0.00 30.40 0.00 15.20 8.00 0.03 8.92 1.92 0.73
dm-19 0.00 0.00 0.00 0.90 0.00 1.80 0.00 0.90 2.00 0.01 9.22 6.78 0.61
dm-20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

:roll:

[naparuba]

Le disque à l'air plutôt tranquille. Je n'arrive pas à comprendre le %sys. Il y a beaucoup de trafic réseau sur la machine? Car tu as largement assez de ram, les I/O disques sont tranquilles.

Par contre un load average a 2 avec un seul CPU ca fait mal en effet (vu qu'il n'y a pas d'I/O disques).

Est-ce que tu as un processus qui consomme tout particulièrement de la CPU (genre mysql par exemple)?

[Guigui2607]

J'ai bien un MySQL :roll:
J'ai installé Centreon, mais il n'est pas utilisé pour le moment, je voulais d'abord régler ce problème de latence avant de me lancer dans la configuration de Centreon en prod...
Actuellement, le service MySQL tourne, mais 'à vide'.

[naparuba]

Donc la charge cpu n'est que pour Nagios. Je n'arrive tout de même pas à m'expliquer ce % de sys. A part de I/O je ne vois pas trop ce que ça peut être. Peu être le nombre de fork mais bon ce n'est pas monstrueu non plus.

[Guigui2607]

Je vais essayer de stopper MySQL pour voir... :roll:

[naparuba]

Lors d'un top, qui consomme le cpu?

[vcarp]

Comment j'ai trouvé ?
En réfléchissant aux causes possibles de ralentissement étant donné la Rolls dont je dispose.

Pour Guigui, n'y a-t-il pas un problème aussi avec http ?
Centreon 1 est très gourmand dans ce domaine car écrit en PHP (je sais que tu ne l'utilises pas, mais beaucoup de connexions sur Nagios peut provoquer des engorgements). J'ai hâte d'essayer le couple Nagios 3/Centreon 2 que j'attends depuis la fin de l'année dernière.
Une autre source d'engorgement, peut être, est qu'un nombre élevé de services créé un très gros ficheir de status qui est écrit et lu fréquemment.
Je n'ai pas fait attention, mais utilises tu l'Aggregated Status Updates Option et si oui, à quelle fréquence ?

[Guigui2607]

@ naparuba > A prioiri c'est Nagios qui consommerait le CPU

@ vcarp > Effectivement, pour le moment Centreon n'est pas utilisé.
En http, j'ai juste la page 'tactical overview' d'ouverte sur mon PC, histoire de suivre ce qu'il se passe.
En effet, beucoup de services (~12000) et comme tu le dis, ça génére des gros fichiers dans var/nagios avec entres autres le status.dat:
objects.cache -> ~13 Mo
retention.dat -> ~16 Mo
status.dat -> ~ 15 Mo

L'option 'Aggregated Status Updates' est activée.
Le 'status_update_interval' est à 60

retain_state_information=1
use_retained_scheduling_info=0
use_retained_program_state=1

max_service_check_spread=30
max_host_check_spread=30

J'ai coupé le service MySQL il y a ½ heure, pas de changement significatif.

Sinon actuellement, j'ai 53 serveurs down... :roll:

[Guigui2607]

Est-ce que d'après vous remplacer les NRPE par des NSCA pourrait améliorer l'architecture?
Est-ce que Nagios n'est il pas débordé par toutes les requêtes qu'il doit envoyer puis traiter à leur retour ?
Est-ce que plus de 50 serveurs down, c'est pas trop ?

Bref, je commence à désespérer un peu à trouver LA solution :sad:

[naparuba]

Il parait que oui, une architecture passive est plus scalable qu'une active. Tu utilise le SSL sur nrpe?

Pour les 50 serveurs down, ceci cré de la latence c'est clair, mais il me semble au vu du nagiostat qu'en moyenne le check host est assez rapide.

[Guigui2607]

Oui SSL est utilisé avec NRPE...

Mais, bon, je me vois mal refaire l'architecture des 1900 serveurs et 12000 services via NSCA... Bref, c'était juste pour en être sûr.

Bon, je vais continuer à creuser un peu :roll: on ne sait jamais :wink:

[naparuba]

Tu m'etonnes. Puis en gestion de conf ce n'est pas vraiment pareil :(

[vcarp]

Attention aussi, avec NSCA, au goulot d'étranglement que peut être le fichier command de Nagios. Ma première archi était sous cette forme, trois serveurs sur des réseaux différents renvoyant leurs résultat vers un serveur passif centralisé. Nous en sommes vite revenus à cause de pertes de données entre les deux. Le serveur central n'arrivait pas à "vider" suffisamment rapidement le pipe.

[Guigui2607]

Ok, merci c'est bon à savoir :wink:

[Guigui2607]

Bon j'ai monté un serveur identique à celui que j'ai en prod.
Les quelques tests déjà effectués montrent (comme prévu) de meilleurs performances avec la v3... Bon, je ne peux pas reproduire la charge que j'ai en prod (~2000 serveurs & ~11000 services), mais avec une vingtaine de hosts et en simulant des pannes X ou Y, on arrive à se donner une (petite) idée de ce que ça pourrait donner en réel en prod :roll:

Il ne me reste plus qu'à étudier pour établir une procédure de migration d'une v2.6 à une v3.0.3 (sortie ces derniers jours) pour minimiser au maximum la durée de coupure du service. Est-ce que le fait de replaquer (à l'arrache) tous les fichiers *.cfg d'un nagios 2.6 sur un nagios 3.0 suffit... :roll: Je doute pour le nagios.cfg entre autres...

Voilà, je essayer de trouver une procédure de migration assez rapidement car ce problème de latence persiste toujours :evil: mais reste tout de même stabilisée :mrgreen: à plus de 300s... (avec une moyenne de 50 hosts down aujourd'hui...)

Bon, bah au boulot maintenant !!

[naparuba]

Je suis parti en prod sur v3 avec les même cfg et ça passe. Par contre ensuite l'utilisation des acks et des commentaires est à bannir car ceci cause de petits soucis à Centreon 1.4.

[Guigui2607]

Sans rien modifier dans les fichiers cfg, ça fonctionne ?!?
Ça, ça pourrait être cool :cool:

Pour ce qui est des acks et des comments, ils ne sont pas utilisés.
Et le Centreon qui est installé, il n'est pas 'actif' volontairement, justement à cause de cette latence.

C'est une piste intéressante, je vais voir ce que ça donne en test...

[naparuba]

Oui, il crie un peu sur le nagios.cfg, mais juste des warning sur certains paramètres qui ne sont plus nécessaires.

[Guigui2607]

Bon bah du moment qu'il ne hurle pas trop fort avec des errors :mrgreen:
Je vais voir ce que ça donne alors... Mais c'est vrai que ça pourrait me permettre de gagner du temps...

[Morkxy]

Desoler tout le monde, mais je viens vous em.... avec mes petits soucies :D

J'ai également des sacrées latence ! Voici le résultat de la commande nagiostats chez moi [si cela fait parler quelqu'un...]

Nagios Stats 2.10
Copyright (c) 2003-2007 Ethan Galstad (www.nagios.org)
Last Modified: 10-21-2007
License: GPL

CURRENT STATUS DATA
----------------------------------------------------
Status File: /usr/local/nagios/var/status.log
Status File Age: 0d 0h 0m 1s
Status File Version: 2.10

Program Running Time: 2d 16h 44m 45s
Nagios PID: 28337
Used/High/Total Command Buffers: 0 / 300 / 4096
Used/High/Total Check Result Buffers: 0 / 20 / 4096

Total Services: 242
Services Checked: 242
Services Scheduled: 242
Active Service Checks: 242
Passive Service Checks: 0
Total Service State Change: 0.000 / 46.780 / 0.373 %
Active Service Latency: 273.254 / 463.081 / 335.912 sec
Active Service Execution Time: 0.028 / 13.006 / 2.083 sec
Active Service State Change: 0.000 / 46.780 / 0.373 %
Active Services Last 1/5/15/60 min: 2 / 15 / 147 / 197
Passive Service State Change: 0.000 / 0.000 / 0.000 %
Passive Services Last 1/5/15/60 min: 0 / 0 / 0 / 0
Services Ok/Warn/Unk/Crit: 231 / 5 / 2 / 4
Services Flapping: 0
Services In Downtime: 0

Total Hosts: 97
Hosts Checked: 97
Hosts Scheduled: 97
Active Host Checks: 97
Passive Host Checks: 0
Total Host State Change: 0.000 / 10.260 / 0.106 %
Active Host Latency: 0.000 / 344.138 / 316.110 sec
Active Host Execution Time: 0.039 / 12.176 / 2.654 sec
Active Host State Change: 0.000 / 10.260 / 0.106 %
Active Hosts Last 1/5/15/60 min: 25 / 74 / 97 / 97
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 96 / 1 / 0
Hosts Flapping: 0
Hosts In Downtime: 0

Par avance, merci !

[Guigui2607]

Effectivement, pas mal :mrgreen:
Plus sérieusement, dans mon cas, je pense que c'est le nombre de serveurs / services et l'architecture Nagios qui m'a généré un 'grosse' latence...

Dans ton cas, tu as 97 serveurs, dont 1 down... et la grosse majorité des services qui sont OK...

As tu essayé dans un premier temps la commande nagios -s nagios.cfg pour voir ce que nagios te propose comme amélioration ?

Après tu peux voir aussi ce que te remonte la commande 'top' (load-average...)
Il y a aussi certains paramètre du nagios.cfg que l'on peut modifier pour éventuellement tenter d'optimiser un peu la chose :roll:

[naparuba]

Je pense que c'est dû à l'utilisation de la planification des host checks en Nagios2. Vire le check régulier des hosts (ils ne seront vérifiés que si un service à un problème sur l'host) et ta latence devrait descendre en flèche.

Tu peux aussi nous donner le load average de ta machine en effet, ca pourrait aussi être ça.

[Morkxy]

Ah c'est super de vous voir présent dès le lundi matin :)

Je regarde dans vos directions et je vous tiens informé!

Mais en attendant, voici le résultat de la commande (/usr/local/nagios/bin/nagios -s /etc/nagios/nagios.cfg)

HOST SCHEDULING INFORMATION
---------------------------
Total hosts: 97
Total scheduled hosts: 97
Host inter-check delay method: SMART
Average host check interval: 66.80 sec
Host inter-check delay: 0.69 sec
Max host check spread: 30 min
First scheduled check: Mon Jun 30 09:20:05 2008
Last scheduled check: Mon Jun 30 09:21:11 2008


SERVICE SCHEDULING INFORMATION
-------------------------------
Total services: 242
Total scheduled services: 242
Service inter-check delay method: SMART
Average service check interval: 16479.67 sec
Inter-check delay: 7.44 sec
Interleave factor method: SMART
Average services per host: 2.49
Service interleave factor: 3
Max service check spread: 30 min
First scheduled check: Mon Jun 30 09:30:07 2008
Last scheduled check: Mon Jun 30 10:00:00 2008


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


PERFORMANCE SUGGESTIONS
-----------------------
* Host checks might be scheduled too closely together - consider increasing 'check_interval' option for your hosts

et le average :
load average: 0.40, 0.51, 0.64

et le 'top' d'un ps aux :


USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
nagios 28337 2.4 0.6 20716 2004 ? Ssl Jun27 98:28 /usr/local/nagios/bin/nagios -d /usr/local/nagios/et
nagios 14766 0.2 0.4 4176 1468 ? S 09:36 0:00 /bin/sh /usr/local/nagios/libexec//check_ping_visio
root 28340 0.1 3.0 39844 9964 ? Sl Jun27 6:03 /usr/bin/perl -w /usr/local/oreon/ODS/ods
www-data 2737 0.1 2.8 24072 9184 ? S Jun27 4:56 /usr/sbin/apache2 -k start
mysql 2153 0.1 12.3 132540 39792 ? Sl Jun27 4:43 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/m
www-data 2506 0.1 3.1 25104 10000 ? S Jun27 4:27 /usr/sbin/apache2 -k start
www-data 6953 0.0 3.1 24992 9996 ? S Jun27 4:07 /usr/sbin/apache2 -k start
www-data 2504 0.0 3.0 24996 9936 ? S Jun27 3:47 /usr/sbin/apache2 -k start
www-data 2502 0.0 3.1 25104 10060 ? S Jun27 3:30 /usr/sbin/apache2 -k start
www-data 2503 0.0 2.9 24344 9540 ? S Jun27 3:23 /usr/sbin/apache2 -k start
www-data 2505 0.0 2.8 24052 9116 ? S Jun27 3:12 /usr/sbin/apache2 -k start
www-data 2762 0.0 3.1 25204 10048 ? S Jun27 3:00 /usr/sbin/apache2 -k start
root 7952 0.0 0.5 4028 1780 pts/2 Ss 09:18 0:00 -bash
root 7922 0.0 0.7 7860 2364 ? Ss 09:18 0:00 sshd: root@pts/2
root 28223 0.0 0.7 7864 2360 ? Ss 08:46 0:00 sshd: root@pts/1
root 1 0.0 0.1 1944 636 ? Ss Jun27 0:22 init [2]
root 21170 0.0 0.3 3404 980 ? Ss Jun27 0:18 /usr/sbin/cron
root 2054 0.0 0.7 3708 2300 ? Ss Jun27 0:13 /sbin/syslog-ng -p /var/run/syslog-ng.pid
root 28225 0.0 0.5 4032 1772 pts/1 Ss+ 08:46 0:00 -bash


A plus tard...

[naparuba]

Je vote pour le host check, 97 checks qui prennent en moyenne 2.5s ca fait short à tenir en 5min (ce n'est pas parallélisé).

[Morkxy]

Bravo, car vous avez bien répondu à mon probléme ! J'ai maintenant vu mon load average chuter ! :D et terminer la latence !
Tout remarche, mes graphiques refonctionnent aussi du coup !

Ce que j'ai fais :
Enlever tout les check ping des host, mais gardé que les services de ping etc...

Merci à vous deux pour votre soutien et votre disponibilitée !

J'espere que tou ca tiendra...

[naparuba]

Ne t'inquiète pas, c'est robuste comme petite bête ;)

[Guigui2607]

Cool :cool:

Juste pour info, peux tu nous donner la latence que tu as maintenant?
C'est juste pour me donner une réelle idée du changement que cela produit !!!

[Morkxy]

pas de probleme :)

load average: 0.52, 0.53, 0.54 (c'est variable..)

nagiostat :

CURRENT STATUS DATA
----------------------------------------------------
Status File: /usr/local/nagios/var/status.log
Status File Age: 0d 0h 0m 7s
Status File Version: 2.10

Program Running Time: 0d 0h 34m 45s
Nagios PID: 28337
Used/High/Total Command Buffers: 0 / 300 / 4096
Used/High/Total Check Result Buffers: 0 / 12 / 4096

Total Services: 242
Services Checked: 242
Services Scheduled: 242
Active Service Checks: 242
Passive Service Checks: 0
Total Service State Change: 0.000 / 41.320 / 0.404 %
Active Service Latency: 0.021 / 1214813057.569 / 5019940.369 sec
Active Service Execution Time: 0.039 / 12.360 / 1.652 sec
Active Service State Change: 0.000 / 41.320 / 0.404 %
Active Services Last 1/5/15/60 min: 26 / 122 / 184 / 229
Passive Service State Change: 0.000 / 0.000 / 0.000 %
Passive Services Last 1/5/15/60 min: 0 / 0 / 0 / 0
Services Ok/Warn/Unk/Crit: 233 / 4 / 2 / 3
Services Flapping: 0
Services In Downtime: 0

Total Hosts: 97
Hosts Checked: 97
Hosts Scheduled: 0
Active Host Checks: 97
Passive Host Checks: 0
Total Host State Change: 0.000 / 7.630 / 0.079 %
Active Host Latency: 0.000 / 376.369 / 308.132 sec
Active Host Execution Time: 0.024 / 12.171 / 2.841 sec
Active Host State Change: 0.000 / 7.630 / 0.079 %
Active Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 58
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 96 / 1 / 0
Hosts Flapping: 0
Hosts In Downtime: 0


vala

[naparuba]

1214813057.569 s ?????

[Guigui2607]

pas de probleme :)

Active Service Latency: 0.021 / 1214813057.569 / 5019940.369 sec



Eh bé !!! :shock:

[Morkxy]

ouai :d c'est spécial... et je vois pourquoi il me sort ca :roll:

[Guigui2607]

Ça a baisser depuis ?
Parce que si on prend la latence max de 5019940s :arrow: 83665mn :arrow: 1394h :arrow: 58j soit presque 2 mois :shock:

[Morkxy]

Active Service Latency: 0.032 / 1214813057.569 / 5019889.215 sec

Euh.. c'est un bug je dirait, parce que tout à de suite fonctionné dès que j'ai fais vos modifs... mais vraiment immédiatement alors que tout était bloqué depuis des jours !

Alors.. tant pis pour les stats fausses [peut etre que avec le temps.. ou lors d'un prochain reboot...], mais le reste marche a font, et c'est le principale :grin:

[naparuba]

Oui ca doit être un bug de calcul avec une valeur un peu ... étrange :)

Le temps que ca réagit bien pour la plupart de tes checks c'est le principal.

[vcarp]

Je suis content de voir que certains ont résolu leur problème de latence, ce qui n'est pas du tout mon cas. J'ai aussi monté une plateforme annexe pour tester, mais avec le même accès que la production. J'ai supprimé tous les check qui, pour une raison ou une autre, duraient plus de 6 secondes en moyennes. Pourtant la latence reste la même (voir plus bas). Je me suis aussi amusé à compter le nombre de processus nagios à intervalle régulier. Malgré un 'max_concurrent_check' à 2200, j'arrive à des pointes de... 85 process dont 7 pour le serveur apache. Où peut bien se situer la limite qui bloque la possibilité d'avoirplus de serveurs en parallèle ? Mon load average est assez bas, je n'ai aps de wait I/O ou très peu, qu'est ce qui peut bien bloquer ?
Merci d'avance pour vos lumières.

CURRENT STATUS DATA
----------------------------------------------------
Status File: /var/opt/nagios/var/status/status.log
Status File Age: 0d 0h 0m 26s
Status File Version: 2.10

Program Running Time: 0d 0h 19m 2s
Nagios PID: 4332
Used/High/Total Command Buffers: 0 / 15 / 4096
Used/High/Total Check Result Buffers: 100 / 129 / 4096

Total Services: 8789
Services Checked: 7998
Services Scheduled: 7904
Active Service Checks: 8695
Passive Service Checks: 94
Total Service State Change: 0.000 / 75.590 / 0.109 %
Active Service Latency: 0.000 / 709.858 / 449.676 sec
Active Service Execution Time: 0.000 / 14.151 / 0.695 sec
Active Service State Change: 0.000 / 75.590 / 0.075 %
Active Services Last 1/5/15/60 min: 277 / 3036 / 7729 / 7904
Passive Service State Change: 0.000 / 12.370 / 3.224 %
Passive Services Last 1/5/15/60 min: 0 / 0 / 2 / 3
Services Ok/Warn/Unk/Crit: 8606 / 90 / 6 / 87
Services Flapping: 0
Services In Downtime: 0

Total Hosts: 1615
Hosts Checked: 1609
Hosts Scheduled: 0
Active Host Checks: 1615
Passive Host Checks: 0
Total Host State Change: 0.000 / 8.420 / 0.005 %
Active Host Latency: 0.000 / 0.000 / 0.000 sec
Active Host Execution Time: 0.000 / 5.096 / 0.262 sec
Active Host State Change: 0.000 / 8.420 / 0.005 %
Active Hosts Last 1/5/15/60 min: 7 / 38 / 143 / 183
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 1614 / 1 / 0
Hosts Flapping: 0
Hosts In Downtime: 0

[vcarp]

J'ajoute les perfs de ma bécane :

top - 14:53:41 up 5:07, 2 users, load average: 1.72, 1.84, 1.89
Tasks: 126 total, 3 running, 123 sleeping, 0 stopped, 0 zombie
Cpu(s): 15.3% us, 22.0% sy, 0.0% ni, 62.3% id, 0.3% wa, 0.1% hi, 0.0% si
Mem: 3115268k total, 530932k used, 2584336k free, 82120k buffers
Swap: 2097144k total, 0k used, 2097144k free, 209080k cached

[naparuba]

22% de sys tout de même mais bon. Ce que tu peux tenter:
*un ulimit pour pousser au max le nombre de process que peut lancer le user nagios
*si ca ne passe pas, tester en mettant l'ensemble des hosts checks en check_dummy OK et regarder si tu as une baisse drastique de ta latence ou pas.

[vcarp]

Pour le ulimit, ce n'est même pas la peine d'essayer. J'ai fait un petit programme qui ne faisait que des forks pour l'interrompre après plus de 28000 process simultanés.
Pour ce qui est host_check, comme ils ne sont pas systématiques, je ne vois pas ce que ça va changer non plus. Désolé.

[Guigui2607]

Bon, après avoir installé un serveur de test identique à celui de prod, j'ai effectué plusieurs tests:
- Migration d'un Nagios v2.6 à un nagios v3.0.x (Merci au passage à Naparuba pour ses précieux conseils :wink:)
- Test de la conf de prod sur le Nagios 3.0.x. (Sans démarrer le service nagios), voilà ce que le nagios -s nagios.cfg donne:

Nagios 3.0.2
Copyright (c) 1999-2008 Ethan Galstad (http://www.nagios.org)
Last Modified: 05-19-2008
License: GPL

Timing information on object configuration processing is listed
below. You can use this information to see if precaching your
object configuration would be useful.

Object Config Source: Config files (uncached)

OBJECT CONFIG PROCESSING TIMES (* = Potential for precache savings with -u option)
----------------------------------
Read: 0.073134 sec
Resolve: 0.004137 sec *
Recomb Contactgroups: 0.001393 sec *
Recomb Hostgroups: 0.012231 sec *
Dup Services: 0.103067 sec *
Recomb Servicegroups: 0.001245 sec *
Duplicate: 0.074203 sec *
Inherit: 0.012888 sec *
Recomb Contacts: 0.000006 sec *
Sort: 0.000502 sec *
Register: 0.203031 sec
Free: 0.013384 sec
============
TOTAL: 0.499224 sec * = 0.209675 sec (42.00%) estimated savings


Timing information on configuration verification is listed below.

CONFIG VERIFICATION TIMES (* = Potential for speedup with -x option)
----------------------------------
Object Relationships: 2.037243 sec
Circular Paths: 145.207873 sec *
Misc: 0.014635 sec
============
TOTAL: 147.259751 sec * = 145.207873 sec (98.6%) estimated savings


EVENT SCHEDULING TIMES
-------------------------------------
Get service info: 0.056189 sec
Get host info info: 0.007553 sec
Get service params: 0.000004 sec
Schedule service times: 0.096651 sec
Schedule service events: 0.286963 sec
Get host params: 0.000012 sec
Schedule host times: 0.014754 sec
Schedule host events: 0.168479 sec
============
TOTAL: 0.630605 sec


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: 1863
Total scheduled hosts: 1863
Host inter-check delay method: SMART
Average host check interval: 300.00 sec
Host inter-check delay: 0.16 sec
Max host check spread: 30 min
First scheduled check: Fri Jul 4 15:35:39 2008
Last scheduled check: Fri Jul 4 15:40:38 2008


SERVICE SCHEDULING INFORMATION
-------------------------------
Total services: 11805
Total scheduled services: 11805
Service inter-check delay method: SMART
Average service check interval: 346.84 sec
Inter-check delay: 0.03 sec
Interleave factor method: SMART
Average services per host: 6.34
Service interleave factor: 7
Max service check spread: 30 min
First scheduled check: Fri Jul 4 15:36:28 2008
Last scheduled check: Fri Jul 4 15:42:15 2008


CHECK PROCESSING INFORMATION
----------------------------
Check result reaper interval: 10 sec
Max concurrent service checks: Unlimited


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

Résultats prometteurs :wink:
Le pré-cache pourrait me faire gagner de précieuses secondes :cool:

Reste plus qu'à proposer tout ça pour la prod, et attendre le feu vert...
J'ai franchement hâte de voir ce que ça pourra donner en 'live' sur le serveur de prod :mrgreen:

Je vous tiens au courant !!

[naparuba]

De rien ;)

Pour le cache: j'ai fait un patch (posté sur le forum pour la 3.0.2) pour booster le "circular path". Je retrouve le post et je te le redonne. (sur mes environnements de tests je passais de 70s à 0.1 :) )

Et hop:
http://forum.centreon.com/showthread.php?t=5234&highlight=patch

[Guigui2607]

Merci, je vais regarder tout ça à tête reposée... :wink:
Et vais préparer soigneusement la migration de mon serveur de prod :mrgreen:

[Guigui2607]

Hello :wink:

Bon, je n'ai pas encore pris le temps de regarder ton patch, mais c'est vrai que le "circular path" prend un certains temps...

Ça y est, de retour de congés (juste 1 semaine :cry:) j'ai réussi à prévoir la migration de mon serveur de prod demain après-midi... J'ai hâte de voir le résultat (niveau performances)

Je suis en train de préparer un maximum de chose pour que la coupure soit la plus courte possible.

Je vous tiens au courant des changements :wink:

[Guigui2607]

Nagios 3.0.2
Copyright (c) 1999-2008 Ethan Galstad (http://www.nagios.org)
Last Modified: 05-19-2008
License: GPL

[...]

HOST SCHEDULING INFORMATION
---------------------------
Total hosts: 1863
Total scheduled hosts: 1863
Host inter-check delay method: SMART
Average host check interval: 300.00 sec
Host inter-check delay: 0.16 sec
Max host check spread: 30 min
First scheduled check: Fri Jul 4 15:35:39 2008
Last scheduled check: Fri Jul 4 15:40:38 2008

[...]

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

Y'a un truc dont je viens de me rendre compte à l'instant en préparant la migration.
Il semblerait que les checks des hosts soient scheduled... :roll:
Il me semblait pourtant avoir vérifié qu'ils ne l'étaient pas :confused:
Je vais voir aussi en même temps pour les rendre "non scheduled".

[Guigui2607]

Re... :wink:

Juste une question de dernière minute sur laquelle je viens d'avoir un doute :shock:
Concernant mes hosts scheduled:
Dans le hosts.cfg, une 'notification' est mise en place avec un "event_handler" (host-notify-by_snmp) avec event_handler_enabled à 1 dans le template.

Ensuite chaque host a, dans sa définition, un check_period avec un timeperiod.
Mon doute est sur le fait de changer le check_period de chaque host en none :roll:

Si je passe tous les check-period de mes host à none, est-ce que mes event_handler seront toujours envoyés :?:

Merci d'avance (pour m'ôter ce doute !!)

[naparuba]

N'ayant jamais utilisé les event je ne sais pas trop. Si test hosts ne sont jamais checkés (none) je pense que ca ne sera jamais appelé (sauf en cas de check forcé).

[vcarp]

Il n'y a pas de raison pour que le event_handler ne soit pas appelé.
Si il y a un événement tel qu'un changement d'état, il y a appel à l'event_handler, ainsi qu'au mécanisme de notification sinon, il serait impossible d'avoir des alertes passives.

[Guigui2607]

Merci à vous 2 pour ces réponses rapides :wink:
J'ai le nez dans la doc Nagios, et à priori rien ne lie les event_handler aux check_periods.
Comme le dit vcarp, "Il n'y a pas de raison pour que le event_handler ne soit pas appelé."

Encore Merci, me voilà rassuré :mrgreen: Plus sérieusement, j'avais 'peur' de l'existence d'un éventuel lien en les event_handler et les check_period...

Je vais donc pouvoir modifier ces check_periods pour mes hosts... :wink:

[Guigui2607]

Bon bah va y est, le serveur est migré en nagios v3.0.3... :cool:
Aucun problème lors de cette migration. Tout roule. En ¼h, tout était ok.

Mais pour le moment, la latence persiste encore :cry:
Et je n'ai pas eu le temps de modifier mon fichier hosts.cfg.
Au passage, j'ai constaté quelque-chose de "bizarre" :-?

J'ai lance un nagiostat avec la version 2.6 précédemment installée:
Nagios Stats 2.6
Copyright (c) 2003-2005 Ethan Galstad (www.nagios.org)
Last Modified: 11-27-2006
License: GPL

CURRENT STATUS DATA
----------------------------------------------------
Status File: /var/nagios/status.dat
Status File Age: 0d 0h 0m 8s
Status File Version: 2.6

Program Running Time: 14d 3h 42m 23s

[...]

Total Hosts: 1846
Hosts Checked: 1846
Hosts Scheduled: 0
Active Host Checks: 1846
Passive Host Checks: 0
Total Host State Change: 0.000 / 8.420 / 0.005 %
Active Host Latency: 0.000 / 0.000 / 0.000 sec
Active Host Execution Time: 0.065 / 10.075 / 0.202 sec
Active Host State Change: 0.000 / 8.420 / 0.005 %
Active Hosts Last 1/5/15/60 min: 4 / 77 / 150 / 227
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 1809 / 37 / 0
Hosts Flapping: 0
Hosts In Downtime: 0
Ce dernier affiche un nombre de 'Hosts Scheduled' à 0

Un nagios -v me donne ce qui suit avec la 2.6:
Nagios 2.6
Copyright (c) 1999-2006 Ethan Galstad (http://www.nagios.org)
Last Modified: 11-27-2006
License: GPL

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: 1846
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

[...]

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

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


J'ai gardé la même configuration et installé la v3.0.3.
J'ai relancé un nagiostats (v3.0.3.) et voilà ce que j'obtiens:
Nagios Stats 3.0.3
Copyright (c) 2003-2008 Ethan Galstad (www.nagios.org)
Last Modified: 06-25-2008
License: GPL

CURRENT STATUS DATA
------------------------------------------------------
Status File: /var/nagios/status.dat
Status File Age: 0d 0h 0m 36s
Status File Version: 3.0.3

Program Running Time: 0d 0h 29m 49s
Nagios PID: 786
Used/High/Total Command Buffers: 0 / 0 / 4096

[...]

Total Hosts: 1846
Hosts Checked: 1846
Hosts Scheduled: 1846
Hosts Actively Checked: 1846
Host Passively Checked: 0
Total Host State Change: 0.000 / 4.280 / 0.018 %
Active Host Latency: 0.000 / 703.662 / 631.575 sec
Active Host Execution Time: 0.024 / 4.215 / 0.124 sec
Active Host State Change: 0.000 / 4.280 / 0.018 %
Active Hosts Last 1/5/15/60 min: 24 / 435 / 1658 / 1846
Passive Host Latency: 0.000 / 0.000 / 0.000 sec
Passive Host State Change: 0.000 / 0.000 / 0.000 %
Passive Hosts Last 1/5/15/60 min: 0 / 0 / 0 / 0
Hosts Up/Down/Unreach: 1817 / 29 / 0
Hosts Flapping: 0
Hosts In Downtime: 0

Active Host Checks Last 1/5/15 min: 121 / 575 / 1814
Scheduled: 107 / 541 / 1710
On-demand: 14 / 34 / 104
Parallel: 108 / 545 / 1725
Serial: 0 / 0 / 0
Cached: 12 / 30 / 89
Passive Host Checks Last 1/5/15 min: 0 / 0 / 0
Active Service Checks Last 1/5/15 min: 721 / 3620 / 10633
Scheduled: 721 / 3619 / 10629
On-demand: 0 / 1 / 4
Cached: 0 / 0 / 0
Passive Service Checks Last 1/5/15 min: 0 / 0 / 0

External Commands Last 1/5/15 min: 0 / 0 / 0

De même avec le nagios -v de la v3.0.3:
Nagios 3.0.3
Copyright (c) 1999-2008 Ethan Galstad (http://www.nagios.org)
Last Modified: 06-25-2008
License: GPL

[...]

HOST SCHEDULING INFORMATION
---------------------------
Total hosts: 1846
Total scheduled hosts: 1846
Host inter-check delay method: SMART
Average host check interval: 300.00 sec
Host inter-check delay: 0.16 sec
Max host check spread: 30 min
First scheduled check: Tue Jul 22 15:27:16 2008
Last scheduled check: Tue Jul 22 15:32:15 2008

[...]

CHECK PROCESSING INFORMATION
----------------------------
Check result reaper interval: 10 sec
Max concurrent service checks: Unlimited


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

La configuration est identique, cependant la v2.6 me dit que les check_hosts ne sont pas scheduled alors que la v3.0.3 me dit le contraire... :roll:

Je vais voir l'histoire de mon fichier hosts.cfg...

[naparuba]

Un champ est rajouté pour l'élément host dans Nagios3, suivant la valeur qu'il a par défaut, nagios3 va le considéré comme "à checker" alors que nagios2 lui ne le connait pas et se comporte comme avant.

[Guigui2607]

Mais comme j'ai repris la conf de la 2.6 sans rien changer, ce nouveau champ n'existait pas...

Voilà une partie de mon hosts.cfg, d'abord le generic-host:
define host {
name generic-host
notifications_enabled 1
event_handler host-notify-by-snmp
event_handler_enabled 1
flap_detection_enabled 1
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
register 0
max_check_attempts 10
notification_interval 120
notification_period 24x7
notification_options d,u,r
contact_groups admins
}
Puis pour chaque host:
define host {
use generic-host
host_name $HOSTNAME
check_command check-host-alive
check_period timeperiod_x
}

A priori, avec cette conf de host, la v2.6 les ne les considérait pas comme "à checker" mais la v3.0.3... ...Oui :roll:

[surcouf]

Mais comme j'ai repris la conf de la 2.6 sans rien changer, ce nouveau champ n'existait pas...

[...]

A priori, avec cette conf de host, la v2.6 les ne les considérait pas comme "à checker" mais la v3.0.3... ...Oui :roll:
Il n'a pas été rajouté, ce champ.
Simplement, si tu lisais les Changelog[1], tu saurais qu'à partir de Nagios 3, les vérifications des hôtes sont ENFIN paralléllisées, tout comme le sont les services. Cela amène un changement de comportement par défaut radical de la part de Nagios, à savoir qu'il peut effectuer sans perte de performance les vérifications normales, selon les intervales définis, des hôtes comme celles des services. Voilà pourquoi tu vois apparaît « comme par magie » tes 1846 hôtes dans la liste de vérifications à faire.


[1]: voir le n°17: http://nagios.sourceforge.net/docs/3_0/whatsnew.html

[Guigui2607]

Il n'a pas été rajouté, ce champ.
Simplement, si tu lisais les Changelog[1], tu saurais qu'à partir de Nagios 3, les vérifications des hôtes sont ENFIN paralléllisées, tout comme le sont les services. Cela amène un changement de comportement par défaut radical de la part de Nagios, à savoir qu'il peut effectuer sans perte de performance les vérifications normales, selon les intervales définis, des hôtes comme celles des services. Voilà pourquoi tu vois apparaît « comme par magie » tes 1846 hôtes dans la liste de vérifications à faire.


[1]: voir le n°17: http://nagios.sourceforge.net/docs/3_0/whatsnew.html

Merci Surcouf, j'avais lu les Changelog de la v3, je savais pour les vérifications des hosts parallélisés, c'est d'ailleurs pour ça que je suis passé à la v3.
Tout ceci dans l'espoir de réduire une latence persistante avec la v2. (d'où l'origine de ce thread :wink:)

Pour le moment, la v3 n'a pas amélioré les performances (latence).
Du coup, je me demandais, même s'ils ont maintenant parallélisés, s'il ne fallait pas les "non-scheduler" pour faire baisser ma latence :?

Edit: L'histoire, c'est que j'ai constamment une 30aines de hosts qui sont down (jamais les mêmes :wink:) et que j'ai l'impression que ce sont eux qui font augmenter la latence. Je cherche donc un moyen pour palier tout ça !!

[Guigui2607]

Ce que j'essaye de comprendre, c'est ce qu'il se passe réellement dans Nagios quand un host est down...

J'ai ~1800 hosts avec une moyenne de 6 services checkés par host.
Aujourd'hui, j'ai 37 hosts down, ce qui représente 6*37=222 services NOK...

Si j'ai bien compris - corrigez-moi si je dis des bêtises - lorsqu'un service est NOK sur un host, Nagios va tester ce host (check-host-alive) pour s'assurer de son état (UP / DOWN) afin d'être sûr de ne pas effectuer des checks de services inutiles sur des hosts réellement down.

Je vois bien que lorsque le nombre de hosts down diminue sensiblement, la latence suit le même chemin...
Existe-t'il un moyen de remédier à ce problème de latence? :roll:

[vcarp]

J'ai cru comprendre également qu'il pouvait y avoir d'autres critères.
Ainsi, les plugins "parlent" avec Nagios à l'aide d'un pipe. Or celui ci a une dimension maximum qui peut bloquer les plugins en attente le temps pour nagios de traiter la sortie et vider le buffer. S'il y a beaucoup de check à faire dans un temps restreint, celà ne provoque-t-il pas une certaine latence également ?

[DonKiShoot]

Je confirme l'existence de cette hypothèse car j'ai déjà suivi des files de discussions la dessus avec des mecs calés.
Si ce n'est pas sur ce forum c'est sur celui là : http://forums.bfl-solutions.eu/ ou peut-être sur la mailing list nagios.

Reste à retrouver ces discussions ;)

[naparuba]

Dans Nagios3 ce buffer se règle il me semble, faut que je retrouve le paramètre.

Edit: tente de tracé ce qui est utilisé actuellement cf en bas de la page http://nagios.sourceforge.net/docs/3_0/mrtggraphs.html

[Guigui2607]

Merci pour ce "tuyau" :mrgreen: Je vais aussi chercher dans ce sens.

En fait, je cherche à trouver tout ce qui pourrait générer une latence... et rectifier le tir.
L'inconvénient, c'est que c'est un serveur de prod et que je ne peux pas faire n'importe quoi en 'Live' et je ne peux pas reproduire en test la charge que j'ai en prod :roll:

[Guigui2607]

Bon, j'ai la possibilité de faire des tests "en live" sur mon serveur de prod en ce qui concerne la configuration de Nagios...

Je vais voir ce que je peux faire cet après-midi avec tous vos conseils. :wink:

[Guigui2607]

Je graph avec MRTG et surveille les performances de mon Nagios...

- j'ai repris un fichier de configuration de nagios v3 pour reprendre mes paramètres de la 2.6.
- J'ai essayé d'augmenter la taille du buffer (doublé), sans réel succès.
- J'ai tenté du jouer avec le max_concurent_checks et le check_result_reaper_frequency... Pas mieux...
- J'ai tenté le use_large_installation_tweaks=1 ... la latence a bien baissé, mais j'ai eu plein de services qui sont passés en Critical... donc pas mieux

:cry:

[Guigui2607]

Je commence à sérieusement désespérer... :cry:

A chaque modif effectuée, la latence descend à 200~300s puis au bout d'½ heure, je plafonne comme avant à 700~800s :shock: (30 hosts down)

J'ai modifié la max_concurrent_cheks avec le check_result_reaper_frequency...
J'ai essayé d'augmenter le buffer...
J'ai stoppé les checks_hosts...
J'ai modifié mon hosts.cfg pour ajouter un check_interval toutes les 10mn...
J'ai passé retain_state_information à 0...

La seul chose qui aura fait baisser la latence, c'est l'option "use_large_installation_tweaks=1", mais elle m'a généré plein de critical dans la foulée...

J'ai encore 2 hypothèses:
- le grand nombre de dépendances de services (+ de 23000 !)
- les checks_interval trop courts :roll: Pas le temps de finir tous les checks avant une nouvelle série ???

Edit: J'ai supprimé les dépendances, ça ne change rien.
Il me reste la dernière hypothèse, les checks_interval trop courts...

A moins que vous ayez d'autres pistes intéressantes :roll:

[Guigui2607]

J'ai aussi testé avec un check_interval identique pour tous les services et hosts à 10mn.
Ça ne change rien, la latence reste la même.
Me voila donc sans autre piste :cry:

Pour résumer:
+1800 Hosts
+11000 Services
1 latence de 600s (10mn!!) en moyenne cette dernière semaine.

Actions déjà tentées sans réel résultat:
- Passage d'un v2.6. à une v3.0.3.
- Modification max_concurrent_check / reaper_frequency
- Agmentation buffer
- Arrêt des hosts_checks
- Modification des hosts_check intervals pour les passer à 10mn
- Modification des services_check intervals pour les passer à 10mn
- Suppression de toutes les dépendances

A chaque modification de chacun de ces paramètres, la latence est descendue tranquillement (jusqu'à environ 200s) durant les 20~25mn suivant le reload/restart de Nagios ensuite, elle est remontée à 600s...

En gros, à chaque reload/restart de Nagios, la latence descend quelque soit le paramètre modifié puis elle remonte ?!?

Le seul paramètre modifié qui ait fait descendre la latence est l'option "use_large_installation_tweaks=1". Le seul "hic" c'est qu'en contrepartie, j'ai eu toute une floppée de critical dans Nagios. Sûrement dûs aux variables de macros...

Voila, voila... Pas glop, pas glop tout ça... Je poursuis toujours mes investigations... On ne sait jamais ?

[naparuba]

Arf, là malheureusement je ne vois pas trop pas où chercher. Poste sur la mailing nagios-user, certains auront peut être des idées pour t'aider.

[naparuba]

Petite question cependant: ton serveur nagios est un serveur physique ou une machine virtuelle?

[Guigui2607]

Celui-là est un serveur physique :roll:

Je pense définitivement qu'il est trop "chargé" (+1800 hosts / +11000 services)...
A part ça, je ne vois rien d'autre...

[naparuba]

Tu as beaucoup de load average? Le processus httpd est-il souvent sollicité (sur mon serveur par exemple j'ai plus de charge à cause d'apache qu'a cause de nagios...)?

Sinon les tweaks c'est l'activation de 3 astuces, tu peux les tenter une à une. Elles sont dispos sur http://nagios.sourceforge.net/docs/3_0/configmain.html juste en dessous de tweaks (free_child_process_memory, child_processes_fork_twice et enable_environment_macros).

[Guigui2607]

top - 13:41:40 up 446 days, 20:49, 2 users, load average: 1.81, 2.10, 2.09
Tasks: 179 total, 2 running, 177 sleeping, 0 stopped, 0 zombie
Cpu(s): 37.6% us, 36.6% sy, 0.2% ni, 24.8% id, 0.8% wa, 0.0% hi, 0.0% si
Mem: 4149216k total, 1510156k used, 2639060k free, 242368k buffers
Swap: 2064376k total, 21272k used, 2043104k free, 393220k cached

Load_average pas top quand même... :roll:

De temps en temps un pic apache...

C'est vrai, je ne les ai pas tenté une par une les options "tweak", je vais voir ça, de toutes façons, j'ai tout à y gagner !!

[naparuba]

Un seul cpu non? Ce qui me fait le plus ticker c'est le 36% de temps système tout de même.

[Guigui2607]

Oui un seul CPU... (2,8 GHz)
4 Go RAM & 2 disques de 36 Go en RAID1...

[naparuba]

D'après un de tes anciens iostat, tu ne faisais pas trop d'I/O disque, donc le %sys doit vraiment être du au système pour gérer les fork et cie. Tentes donc en priorité le fait de ne plus faire de double fork pour voir.

[Guigui2607]

Bon, je viens de passer le "free_child_process_memory" à 1...
La latence vient de descendre en flèche...
...Pour se stabiliser pour le moment à 4s :shock:

Par contre, côté load_average, ça fait un peu peur !
top - 14:07:57 up 446 days, 21:15, 2 users, load average: 6.50, 6.58, 4.86
Tasks: 344 total, 1 running, 339 sleeping, 0 stopped, 4 zombie
Cpu(s): 26.7% us, 16.7% sy, 0.0% ni, 53.2% id, 3.5% wa, 0.0% hi, 0.0% si
Mem: 4149216k total, 1820812k used, 2328404k free, 247668k buffers
Swap: 2064376k total, 21272k used, 2043104k free, 411060k cached

[naparuba]

Regardes comment ça va évoluer, le load devrait descendre. Il est lancé depuis combien de temps nagios?

[Guigui2607]

Ça va faire une vingtaine de minute que je viens de faire un reload après la modif...
Je surveille :roll:

[naparuba]

Etrange car un load a 6 avec 1 running et un idle à 50% c'est vraiment space... Est-ce possible de faire un restart plutôt qu'un reload? Tu peux vérifier combien de process nagios tu as?

[Guigui2607]

top - 14:20:54 up 446 days, 21:28, 2 users, load average: 6.74, 6.67, 6.25
Tasks: 246 total, 16 running, 230 sleeping, 0 stopped, 0 zombie
Cpu(s): 32.9% us, 18.6% sy, 0.0% ni, 32.2% id, 16.3% wa, 0.0% hi, 0.0% si
Mem: 4149216k total, 1610588k used, 2538628k free, 250708k buffers
Swap: 2064376k total, 21272k used, 2043104k free, 411140k cached
Voilà ce que j'ai quelques minutes après le reboot...

Est-ce que maintenant les variables max_concurrent_check et reaper_frequency n'auraient pas plus d'effet que précédemment :roll:

[naparuba]

Et question latence ça va? La consultation web n'est pas (trop) ralentie?

Pour les paramètres tu peux tester, mais si tu as déjà une bonne latence, peut être pas trop la peine de tester en prod.

[Guigui2607]

La latence s'est stabilisée à 4s!
J'avais lu dans la docs nagios, que certaines valeurs des variables max_concurrent_check et reaper_frequency pouvaient faire augmenter le load_average...

Ça fait 5mn que je viens de faire un restart de Nagios...
Je viens de voir à l'instant que le nombre de services PENDING vient d'augmenter
et du coup la latence suit :evil:

Je regarde d'un peu plus prés...

Edit: C'est bon, j'ai vu ce qu'il s'est passé, les gens de la prod ont fait des modifs de leur côté sur les fichiers cfg...
Je rectifie tout ça et te tiens au courant...

Au passage: encore un grand Merci à toi Naparuba !!!!!

[naparuba]

Mais de rien, j'ai beaucoup appris également de ton problème sur comment régler nagios sur un gros environnement. Ca va te laisser du temps pour tester mon patch sur les dépendances désormais ;)

[Guigui2607]

Maintenant oui, je vais pouvoir souffler un peu :mrgreen:

[Guigui2607]

Bon, depuis 8 jours, la latence, qui est bien descendue, s'est stabilisée à 120s.
Ce qui est beaucoup mieux que les 600~700s que j'avais avant... :wink:

Je pense que maintenant ce 'résidu' de latence est dû aux check_interval qui je pense sont trop courts compte tenu du grand nombre de service à checker.
A vérifier puis à modifier...

Durant la nuit, entre 20h et 5h du matin, les hosts et services ne sont pas checkés sur une majorité des serveurs. (Timeperiod...)

Cependant, je constate une chose depuis 1 semaine:
A 5h, quand les checks reprennent, je constate une forte augmentation des alertes 'Critical'. Ces alertes 'supplémentaires' ont pour information "Connection refused or timed out" ou "CHECK_NRPE: Error - Could not complete SSL handshake".
Pour le moment, la solution :roll: que j'ai 'trouvé' est de redémarrer le service nagios pour que tout revienne dans l'ordre dans le ¼h suivant.
J'essaye de comprendre ce qu'il se passe à partir de 5h et ce qui génère ces alertes inutiles... (je vais éplucher de près les logs :-? - Peut-être une piste...)

[vcarp]

J'ai aussi réussi une réduction de la latence drastique avec une version 2 de Nagios. Je me suis intéressé à NDO et à MySQL. En supprimant la purge automatique des tables prévue dans ndo2db et en la remplaçant par un script exécuté une fois par jour, ma latence est passée de plus de 200 secondes à moins de 50. Elle semble s'être stabilisée autour des 47/48 depuis hier soir.
Si quelqu'un est intéressé par le script de purge (je retire ce qui a plus de 24H), pas de problème, le voici :

#!/bin/bash

MYSQL="/opt/mysql/bin/mysql -u ndouser -pxxxxxxx nagios"
STIME=$(date +%s)
((STIME -= 86400))

$MYSQL <<EOT
delete from nagios_timedevents where event_time > 0 and event_time < FROM_UNIXTIME($STIME);
delete from nagios_systemcommands where start_time > 0 and start_time < FROM_UNIXTIME($STIME);
delete from nagios_servicechecks where start_time > 0 and start_time < FROM_UNIXTIME($STIME);
delete from nagios_hostchecks where start_time > 0 and start_time < FROM_UNIXTIME($STIME);
EOT

[Guigui2607]

Effectivement ça peut être intéressant...
Pour ma part, je n'utilise pas (encore) MySQL [NDO] avec mon Nagios...
C'est 'juste' un Nagios 'tout seul' :mrgreen:

Avec la version 3, j'ai trifouillé un peu comme me l'a conseillé Naparuba les options de tuning de Nagios et Ô miracle, la latence est bien redescendu (de + de 600s :shock: à 60~70s ces derniers jours...) Je pense que la latence restante est maintenant due aux check_interval trop court pour certains types de checks :roll:

J'attends la version 2 stable de Centreon (la RC3 est sortie hier soir, c'est bon signe !!) pour essayer de la coupler à mon Nagios 3...

Pour le moment, je creuse toujours autour de mon problème de "CHECK_NRPE: Error - Could not complete SSL handshake" lorsqu'un grand nombre de check reprennent en même temps après une 'pause nocturne'...

Bon j'ai bien pris note de ton astuce 'MySQL', je la garde sous le coude, on ne sait jamais :wink:

[naparuba]

Merci pour le script. Il y a aussi des options dans ndo2db.conf il me semble sur les durées de rétentions.

[vcarp]

ndo2db : S'il y a bien des options, la purge se fait en permanence (sauf à mettre une valeur de 0 pour la durée de vie, ce que j'ai fait).
Latence : ce n'est pas gagné. Ce matin elle a dépassé les 60. Ça monte moins vite, mais ça monte tout de même.

[naparuba]

Ah je pense que je vais mettre 0 à quelques valeurs non utilisées (pour l'instant) car ces purges en continues c'est assez lourd pour la base je trouve. Mieux vaut une bonne purge une fois par jour (sauf si on souhaute garder moins d'une journée bien sûr...).

Pour la latence, d'habitude elle monte beaucoup?

[vcarp]

Elle monte parfois jusqu'à 300 secondes. Je préfère alors redémarrer Nagios pour la réinitialiser.

[Guigui2607]

Re à tous, :wink:

Voilà maintenant un petit bout de temps que mes modifs ont été faites... Cependant, avec ces modifs, le load_average a bien grimpé et le CPU est quasiment tout le temps à 100%...
La latence est devenue stable (~70 - 80s...). Bien mais mais top à mon goût.
Du coup, je remets le nez dans la doc Nagios (RTFM :mrgreen:) dans l'e