xspoon
01-03-2007, 12:22 PM
bonjour,
comme ça à été déja dit mais peut être pas assez clarifié, il est possible par une petite manip d' optimiser la gestion des ressources CPU occupées par nagios, et de ce fait, de permettre de faire tourner plus de services check dans des temps plus court en se rapprochant d'une gestion "temps réel" acceptable de quelques minutes.
il s'agit en fait simplement de réduire la valeur du parametre max_concurrent_checks pour forcer nagios à étaler les checks dans le temps d'une manière la plus égale possible et d'utiliser également le réglage inter_check_delay_method en smart.
le calcul de la valeur max_concurrent_checks dépend du nombre de services a faire tourner et de la frequence des checks , ce qui peut donner la formule magique suivante:
:arrow: max_concurrent_checks = nombre_de_services / fréquence_des_checks en secondes
par exemple:
180 services qui tournent toutes les minutes:
180/60 = 3 checks concurent en max
Cela réduit considerablement le load dû aux checks:
par exemple j'ai une station qui tourne avec ces réglages ( 180 services par minute dont 70 graphiques ) sur un desktop mono-pross celeron 2,6 GHz et 512 Mo de RAM et le load reste à 0.25 en moyenne :D
Avec ces chiffres en théorie je peux quadrupler mon nombre de checks et meme encore multiplier par 5 si je passe sur une fenetre de 5 minutes.
180 * 4 * 5 = 3600 checks toutes les 5 minutes.
Ca voudrait dire que sur un serveur bi-processeur avec assez de mémoire on peut bien arriver à des performances correctes concernant le monitoring en temps réel.
donc , à suivre avec les experiences de chacun.
xspoon.
comme ça à été déja dit mais peut être pas assez clarifié, il est possible par une petite manip d' optimiser la gestion des ressources CPU occupées par nagios, et de ce fait, de permettre de faire tourner plus de services check dans des temps plus court en se rapprochant d'une gestion "temps réel" acceptable de quelques minutes.
il s'agit en fait simplement de réduire la valeur du parametre max_concurrent_checks pour forcer nagios à étaler les checks dans le temps d'une manière la plus égale possible et d'utiliser également le réglage inter_check_delay_method en smart.
le calcul de la valeur max_concurrent_checks dépend du nombre de services a faire tourner et de la frequence des checks , ce qui peut donner la formule magique suivante:
:arrow: max_concurrent_checks = nombre_de_services / fréquence_des_checks en secondes
par exemple:
180 services qui tournent toutes les minutes:
180/60 = 3 checks concurent en max
Cela réduit considerablement le load dû aux checks:
par exemple j'ai une station qui tourne avec ces réglages ( 180 services par minute dont 70 graphiques ) sur un desktop mono-pross celeron 2,6 GHz et 512 Mo de RAM et le load reste à 0.25 en moyenne :D
Avec ces chiffres en théorie je peux quadrupler mon nombre de checks et meme encore multiplier par 5 si je passe sur une fenetre de 5 minutes.
180 * 4 * 5 = 3600 checks toutes les 5 minutes.
Ca voudrait dire que sur un serveur bi-processeur avec assez de mémoire on peut bien arriver à des performances correctes concernant le monitoring en temps réel.
donc , à suivre avec les experiences de chacun.
xspoon.