Dégradation des Performances avec NSCA

[krbian]

Bonjour,

Une nouvelle de taille est apparu durant le déploiement et les tests de charges de NAGIOS.

Une archi distribuée permet de répartir l'ensemble des check sur plusieurs services. Mais la contrepartie a un prix lourd.

je m explique :
Pour chaque service sur un SA le parametre obsess_over_service est à 1 et le ocsp_command lance le send_nsca. Nénamoins le nombre, de paquets NSCA envoyé est très important. Sur le serveur Central pour paquets le daemon NSCA cré un fork pour écrire dans le pipe de nagios (/var/rw/nagios.cmd). Le nombre de notif est tellement important que cet envoi massif génére sur le serveur un blocage est un mise en attente des notif suivante. Ce qui n'est pas génant sur le SI, l'est beaucoup plus sur le SA. En effet un nombre important de connexion de send_nsca sont en TIME_WAIT, sachant que l'oscp_command doit d etre fini pour entamer un nouveau check (pour un service donné). La latence d'un service monte de maniere non négligeable =~ + 30 secondes.

1ere question : l'un de vous a deja rencontré ce probleme?

2ème : une idée sur la solution?

3ème : quel mode de fonctionnement nsca utilisé vous? (deamon, inetd, xinetd)

NOTE : je vais faire des graphs avec la latence moyenne avec différents réglage nagios / mode de nsca

[templuche]

Bonjour,

1ere question : l'un de vous a deja rencontré ce probleme?

Oui, une seule fois à vrai dire, mais c'était sur une architecture très chargée.

2ème : une idée sur la solution?

Plusieurs:
1) https://sourceforge.net/mailarchive/...sg_id=13415884

2) "agréger les ocsp": en fait, ne pas utiliser NSCA et utiliser plutôt la méthode suivante:
- la commande ocsp va écrire dans un fichier temporaire
- à intervalle régulier (toutes les minutes par exemple), écrire dans le fichier nagios.cmd les informations temporaires à l'aide du protocole SSH et de la commande externe PROCESS_SVC_CHECK_RESULT: http://www.nagios.org/developerinfo/...command_id=114

2') Sinon il est possible de faire à peu près la même chose qu'avant: on peut écrire plusieurs lignes dans le send_nsca ; là actuellement, tu n'envoies qu'une seule ligne il faut s'arranger pour en passer plusieurs (je ne l'ai jamais tenté, j'ai préféré le coup du SSH), en gros au lieu de faire un seul printf et de piper à send_nsca, il faut écrire plusieurs lignes sur l'entrée standart de send_nsca (je ne sais pas si je suis clair dans mes explications)

3) mettre la directive command_check_interval à -1 sur le SI (petit rappel, à tout hasard, il arrive que l'on oublie cette directive) et mettre un intervalle de 15 secondes sur les SA

4) ne pas mettre de check actif sur le SI (fait chuter les performances des SA, aussi incroyable que cela puisse paraître)

3ème : quel mode de fonctionnement nsca utilisé vous? (deamon, inetd, xinetd)

daemon... Comme dit au dessus, on peut faire différement.

N'hésite pas à nous dire si cela à améliorer les choses.

[krbian]

merci templuche

1) https://sourceforge.net/mailarchive/...sg_id=13415884

Cette solution met en évidence que le problème se situe sur le test check_icmp d un host sur le SI. Je viens de faire des test avec nagios 2 qui permet d avoir des host passif avec comme check commande un simple echo => meme résultat. Mon soucis se situe plutot au niveau du fifo nagioscmd qui n est pas vidé assez vite. (monté le repertoire $NAGIOS/var/rw/ sur un autre disque physique peut etre ....)

2) "agréger les ocsp": en fait, ne pas utiliser NSCA

solution pas testée qui semble la plus fonctionnel : en divisant le processus d'envoi d'état, du daemon nagios on débloque tres rapidement les oscp_command et il n y a alors aucun impact sur les latences. Néanmoins on perd la rémonté d alerte en temp réel.

3) mettre la directive command_check_interval à -1 sur le SI (petit rappel, à tout hasard, il arrive que l'on oublie cette directive) et mettre un intervalle de 15 secondes sur les SA

J avais déja regardé .... mais je rêve encore que cela puisse changer les choses ^^

4) ne pas mettre de check actif sur le SI (fait chuter les performances des SA, aussi incroyable que cela puisse paraître)

dur dur est l apprentissage des tests de charges....



La solution que je teste actuellement est le remplacement des oscp par les event_handlers. Ainsi je notif le SI que pour des changement d'état => diminution importante des paquet NSCA... en cours d'étude (à suivre)

[julio]

ouias mais pour les eventhandlers c pas top... pour faire remonter toutes les données en base c'est pas bon...

et apr curiosité : cb de services, cb d'host et quel type de machine ?

[templuche]

ouias mais pour les eventhandlers c pas top

Chacun sa solution. Moi, je trouve que c'est une très bonne idée que je garde sous le coude pour le jour où j'en aurais besoin. Il faut juste penser à désactiver le principe de freshness. Cela peut être suffisant dans certains cas : ne recevoir sur le SI que les changements d'états (pour faire simple) et cela reste du temps réel, donc...

De notre côté, nous n'avons pas abordé ce point lors de la réunion car nous considérons que c'est un problème d'architecture dont Centreon n'a pas à se soucier. Il ne faut pas enfermer les utilisateurs de Centreon dans une solution imposée (par exemple NSCA ou SSH ou ...) car c'est trop réducteur et source de discussion interminable. C'est à l'administrateur de s'assurer de cette remontée des informations et non à Centreon. Enfin, cela laisse tout le monde libre d'utiliser la brique logicielle qu'il souhaite.

[krbian]

Bonjour julio,

ouias mais pour les eventhandlers c pas top... pour faire remonter toutes les données en base c'est pas bon...

Pour la remonté les infos en base, j ulitilise les fichiers perdata data , ils sont totalement décallé vis a vis de l'etat des services, l'utilisation du NSCA est justement pour dissocier les processus entre l'état qui doit avoir une remonté en temps réel alors que les données de performance pour les graphs+reporting peuvent etre remontés tout les 30 min, ou toutes les heures ou meme une fois par jours.

et apr curiosité : cb de services, cb d'host et quel type de machine ?

les serveurs sont des :
4 x Intel(R) Xeon(TM) CPU 3.20GHz
avec 2Go de RAM
DD en RAID 5

Pour les benchs, il y a 3 SA et 1 SI pour le moment
300+200+800 services actif => autant de passif sur le SI ( a terme entre 5000 et 6000 environ)
entre 60 et 70% sont ordonnancé toute les 30 sec, => raison pour laquelle les notif NSCA sont aussi nombreuses.

templuche:

Il faut juste penser à désactiver le principe de freshness.

Les freshness vont avoir une autre fonction que :

Attention service non rafraichi depuis X min

mais plutot :

Ok service stable depuis plus de X heures

A allier avec un test du SI vers SA (test) en mode continu.

De notre côté, nous n'avons pas abordé ce point lors de la réunion car nous considérons que c'est un problème d'architecture dont Centreon n'a pas à se soucier. Il ne faut pas enfermer les utilisateurs de Centreon dans une solution imposée (par exemple NSCA ou SSH ou ...) car c'est trop réducteur et source de discussion interminable. C'est à l'administrateur de s'assurer de cette remontée des informations et non à Centreon. Enfin, cela laisse tout le monde libre d'utiliser la brique logicielle qu'il souhaite.

Sur ce point, il est, pour moi, clair que cela n a pas a voir avec l interface de Centreon mais plus avec Nagios dans une archi distribué.

[julio]

Pour la remonté les infos en base, j ulitilise les fichiers perdata data , ils sont totalement décallé vis a vis de l'etat des services, l'utilisation du NSCA est justement pour dissocier les processus entre l'état qui doit avoir une remonté en temps réel alors que les données de performance pour les graphs+reporting peuvent etre remontés tout les 30 min, ou toutes les heures ou meme une fois par jours.

Je me pose une question : Vaut il mieux labourrer la bande passante une fois toutes heures ou une fois par jour, ou alors simplement synchroniser les bases plus souvent par petite touche... le transfert serait alors moins volumineux et une mise a jour plus temps reel... alors que une fois par jour peut durer plus longtemps....

Pour les benchs, il y a 3 SA et 1 SI pour le moment
300+200+800 services actif => autant de passif sur le SI ( a terme entre 5000 et 6000 environ)
entre 60 et 70% sont ordonnancé toute les 30 sec, => raison pour laquelle les notif NSCA sont aussi nombreuses.

ouais va falloir trouver une solution pour diminuer les transferts... c'est vrai que du coup les eventhandlers c pas mal...

1300 checks en 30 s soit : 45 checks a la seconde.... c un peu normal ta surcharge....

je suis donc ok... avec vous sur le reste... c pas centreon qui gere tout ca... Centreon pond les fichiers de conf, recupere les données de perfdata et visualise les etat (a ce moment la plus trop besoin d'afficher l'output... et on gagne du temps de refrraichissement dans le monitoring).

Apres on ajoutera un module de creation de graphs..

[templuche]

Bonjour,

Pour les benchs, il y a 3 SA et 1 SI pour le moment
300+200+800 services actif => autant de passif sur le SI ( a terme entre 5000 et 6000 environ)
entre 60 et 70% sont ordonnancé toute les 30 sec, => raison pour laquelle les notif NSCA sont aussi nombreuses.

Avec quelle version de Nagios? La v2 je suppose non?

[krbian]

la v1 le supporte n ai pas tres stable sur le moyen terme.

par contre la v2 semble mieux tenir

[krbian]

Bonjour,

PI

en cours d'étude voici les problemes que je rencontre :
une latence sur les SA qui augmente réguilèrement mais qui augmente qd meme.

si quelqu un à une idée, je suis preneur )

Note : il y a actuellement 4000 services, (100 sont ordannacés à 30 sec, 3000 à 1 min et le reste > à 5min)

[templuche]

Bonsoir,

il y a actuellement 4000 services, (100 sont ordannacés à 30 sec, 3000 à 1 min et le reste > à 5min)
si quelqu un à une idée, je suis preneur

Augmenter les intervalles de check? :lol:
A mon avis, c'est beaucoup trop! En plus, avec les perfdata, l'OCSP, ça influe sur la charge globale. Quel est l'élément qui est limitant: le CPU, la RAM, les entrées sorties disques, le réseau?

Ce ne serait pas dû à une fuite mémoire de Nagios?

[templuche]

Bonsoir,

Je reprends les chiffres et fait quelques petits calculs dessus.

Sur une minute, Nagios va faire au moins 3200 checks (3000 sur 1 minute et 100*2).

Nagios, quand il fait un check, forke une fois pour la commande à lancer, une fois pour l'OCSP et une fois pour le fichier perfdata. Ce qui fait: 3200 * 3 forks. Il faut que la machine puisse encaisser 9600 création/destruction de process en 1 minute hock:
Ca commence à faire beaucoup. Sans compter le traitement du plugin,le traitement par Nagios du résultat, le calcul de la scheduling queue, l'affichage des résultats, ...

Est ce vraiment des services vitaux qui ont besoin d'être contrôlés toutes les 30 secondes et toutes les minutes? J'ai du mal à voir ce qui peut être si vital que ça. Si c'est si vital, en général, on met en place de la redondance pour que cela n'est pas besoin d'être contrôlé aussi souvent.

[krbian]

Bonsoir templuche,

les nombres de services + hosts annoncés sont cumulatif (vu coté SI)
il y a sur un SA entre 1000=~1400 et il y a trois SA
les tests toutes les 30 sec sont des ping . et les tests toute les min sont des check_traffic (en plus poussé)

je peux jouer sur l'interval de temps pour les traffic.

A vrai dire je pense que le systeme est capable de le supporter. Pour preuve la Latence au lancement de Nagios n est pas excéssive, il est vrai qu elle augmente mais lentement.

[templuche]

Bonjour,

Qu'utilises tu pour les check_ping comme plugin? Le plus rapide est check_icmp. Cependant, il faut que l'utilisateur soit root et le sticky bit soit activé pour que l'utilisateur Nagios puisse exécuter le plugin.

[krbian]

bonjour,

j'utilise le check_fping.
je na ia pas testé le check_icmp, sais tu lequels des deux est le plus rapides entre fping et icmp?