Probléme ODS

[Ludo31]

Bonjour,

Comme de nombreuses personnes sur le forum j'ai pu remarqué des problémes avec le démon ODS (graph avec des trous, voir plus de graphs du tout).
Je me suis donc un peu penché sur la question et je pense peut être avoir un début de solution

En mettant en place un disque virtuel pour placer le service-perfdata, je me suis rendu compte que la place sur le disque diminué alors que les fichiers eux n'augmentaient pas, j'ai donc fait un "lsof | grep deleted" et la je me suis apercu que de nombreux process nagios était en train d'écrire sur le fichier service-perfdata alors que celui-ci était supprimé.

j'ai été voir le script ods, et la je me suis apercu que l'on supprimé le fichier service-perfdata aprés l'avoir lu (ligne 169 'unlink($_[0])')
le souci c'est que ce fichier n'est pas tout de suite recréé et on se retrouve avec des incohérences et des pertes de données.

j'ai donc remplacé ce 'unlink($_[0])' par 'open(PERFDATA,'>'.$_[0])' qui crée un nouveau fichier service-perfdata sans l'effacer (code peut être à améliorer)

j'ai laissé tourné et pour l'instant pas de pb d'écriture sur le fichier et des graphs OK. Si ca peut aider ou faire avancer le schmilblick :D

[julio]

si tu fais ca tu ecrase a chaque fois nan ?

If MODE is '>' , the file is truncated and opened for output, being created if necessary. If MODE is '>>' , the file is opened for appending, again being created if necessary.

ca marche t'es sur ?

[Ludo31]

Ben en fait c'est un peu le but de tout écraser puisque on a plus besoin des données de ce fichier service-perfdata, ils ont été sauvegardé dans service-perfdata_read afin d'être traité pas ODS en vue de les sauvegarder dans la base de donnée mysql et d'être transféré dans les bases RRD.

Du coup ce que je fais c'est qu'au lieu de supprimer complétement le fichier, je ne fais que le purger de son contenu afin qu'il soit toujours présent afin que nagios puisse y rentrer les perfdata

Pour moi ca marche nickel, pour l'instant ca tourne parfaitement, et j'ai pu le probléme d'avoir le démon nagios ou des checks en train d'écrire sur service-perfdata alors qu'il n'y est plus.

[julio]

oula pas catho ton truc... tu efface le fichier a chaque ecriture... je ne comprend pas trop....

ca change koi en fait ?

[Ludo31]

en fait je ne fais que faire ce qui est déjà fait puisque aprés avoir recopier le fichier service-perfdata le script ods lance la suppression du fichier service-perfdata sans le recréer, nagios le recrée mais que quelque temps plus tard ce qui une fenêtre durant laquelle on perd des données

j'explique :
- dans le script original on a aprés le 'copy($_[0], $_[0]."_read"' la commande 'unlink($_[0])' qui va supprimer le fichier en laissant le soin à nagios de le recréer (solution qui pose pb car on se retrouve avec le démon nagios et des checks en train d'écrire sur un fichier qui n'existe plus)
- ma solution (qui n'est peut être pas la plus catho ! :p) et d'ouvrir le fichier en écriture 'open(PERFDATA,'>'.$_[0]' commande qui a pour but d'ouvrir le fichier en écriture et d'effacer le contenu du fichier, puis je ferme le fichier aussitot avec un 'close(PERFDATA);' (cela permet d'avoir toujours le fichier service-perfdata et que les checks et nagios puissent tjs écrire dessus sans à avoir à attendre que nagios le recrée)

PS : j'ai mis 'open(PERFDATA,'>'.$_[0]' car j'ai trouvé que c'était une facon simple de supprimer le contenu du fichier service-perfdata aprés il y en a d'autre

[naparuba]

Ca semble juste en effet. Car cela remplace une suppresion de fichier (unlink) par le vidage (> + close). Je vais tenter pour voir.


Jean

[lindusfree]

Bonjour,

Tout d'abord Meilleurs Voeux à tous le monde, la santé, de nouveau développement, une nouvelle version, et ......

Je ne dirais qu'une chose BRAVO Ludo31 :p :p
J'ai testé cette modif et ca marche nickel, plus un trou sur mes graphes.

On ne sait toujours pas si c'est catho ( comme tu le dis Julio )
mais ca marche.

Merci Merci Merci

[lindusfree]

ARGHHHHHH

Je reviens sur ce que j'ai dit...
Les trous sont de retour, malheur, que c'est dur.

Aprés quelque jour de graphique nickel, et bien j'ai de nouveau des trous
Je vais essayer de relancer le demon ODS pour voir si ca marche mieux

Apres je passerais a la version 1.4.2.1 pour voir si c'est mieux.

Salut

[julio]

attend la 1.4.2.2 stp :) ca va pas tarder... on a une coquille :(

[Ludo31]

Bonjour,

Pour moi ca marche il y a pas de trous, mais a tu décoché dans Oreon/Centreon Data Storage l'option "Déplacer les données après lecture"?? parce que ca fout pas mal le bazar

Combien as tu de graphs a gérer?? nb de fichier rrd?

moi je suis a environ 1000 fichier rrD pour a peu prés 600 graphs et le probléme qui apparait c'est qu'il y a beaucoup de lecture sur le disque (100% utilisation disque) lors du traitement du fichier service perfdata, et plus on va dans le temps plus le temps d'éxécution est long et plus le fichier service-perfdata_read augmente de taille.

j'ai remplacé le type des tables index_data et Metrics en table Memory au lieu de MyIsam (car beaucoup de select sur ses tables), ca a un peu amélioré la chose mais je pense que ce qui me bouffe le plus c'est l'update des fichiers rrd!!:(

je n'ai pas trouvé encore de solution a mon probléme car ces fichiers rrd pésent 6Go (impossible de les stocker en mémoire) alors si quelqu'un a une solution je suis preneur!!

[boyerf]

attend la 1.4.2.2 stp :) ca va pas tarder... on a une coquille :(

Je n'ai pas encore testé la manip de Ludo... mais je pense que cela n'est pas idiot. Il peut tres bien y avoir cet aléa de synchronisation entre processus.
Est ce que tu penses inclure Julio, cette modif ou cet aproche de modification dans ODS ?

PS : Voir aussi ce que je te propose ici (http://forum.oreon-project.org/showpost.php?p=32946&postcount=39)

[julio]

C'est inclu dans la 1.4.2.2 :)

[Ludo31]

Autant pour moi, je viens de modifier la version de rrdtool et maintenant plus de probléme de lecture sur le disque.
j'étais avec la version 1.2.15 (version stable de debian) et la je suis passé à la version 1.2.26 (pour ceux que ca intéresse).

A voir si la version 1.2.19 de la version unstable de debian améliore aussi la chose.

De mon côté je n'est plus de souci, les graphs sont impeccables et le serveur n'est pas chargé. ;)

[julio]

he je me disais aussi ;)

[boyerf]

C'est inclu dans la 1.4.2.2 :)

Hum... probleme... voila ce que j'ai dans le fichier ods de la version 1.4.2.2 :

########################################
# Move perfdata file to tmp file
########################################

sub movePerfDataFile($){
if (copy($_[0], $_[0]."_read")){
writeLogFile("Error When removing service-perfdata file : $!") if (!unlink($_[0]));
return(1);


Et effectivement, mon fichier perfdata-service.log est régulierement effacé... :(

[boyerf]

Bon en attendant le patch, j'ai fait cette modif :

sub movePerfDataFile($){
if (copy($_[0], $_[0]."_read")){
writeLogFile("Error When removing service-perfdata file : $!") if (open(PERFDATA,'>'.$_[0]));
close(PERFDATA);
return(1);


Du coup, ca fonctionne, mais j'ai une erreur dans le fichier ods.log :

1199724406 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724422 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724434 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724445 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724456 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724467 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique

Il gueule mais il remet bien le fichier à 0 sans l'effacer...

Une idée ?

[julio]

je ne comprend toujours pas ou est le problème... Quel est le problème...???

[boyerf]

je ne comprend toujours pas ou est le problème... Quel est le problème...???

Je pensais trouver la modif proposée par Ludo31 dans la version 1.4.2.2 mais ce n'est pas le cas.

J'ai testé cette modification en patchant moi-même ods et cela donne de bon résultat sur mes graphes qui aupparavant etaient pleins de trous.

J'ai juste un warning d'erreur qui se log dans le fichier ods.log

Ludo31, as tu le même message ?

[julio]

nan je n'ai pas patché... je regarde... je ne vois pas de pb d'ecriture et de lecture comme il l'indique... je vais enqueter..

[julio]

en fait je ne fais que faire ce qui est déjà fait puisque aprés avoir recopier le fichier service-perfdata le script ods lance la suppression du fichier service-perfdata sans le recréer, nagios le recrée mais que quelque temps plus tard ce qui une fenêtre durant laquelle on perd des données

j'explique :
- dans le script original on a aprés le 'copy($_[0], $_[0]."_read"' la commande 'unlink($_[0])' qui va supprimer le fichier en laissant le soin à nagios de le recréer (solution qui pose pb car on se retrouve avec le démon nagios et des checks en train d'écrire sur un fichier qui n'existe plus)
- ma solution (qui n'est peut être pas la plus catho ! :p) et d'ouvrir le fichier en écriture 'open(PERFDATA,'>'.$_[0]' commande qui a pour but d'ouvrir le fichier en écriture et d'effacer le contenu du fichier, puis je ferme le fichier aussitot avec un 'close(PERFDATA);' (cela permet d'avoir toujours le fichier service-perfdata et que les checks et nagios puissent tjs écrire dessus sans à avoir à attendre que nagios le recrée)

PS : j'ai mis 'open(PERFDATA,'>'.$_[0]' car j'ai trouvé que c'était une facon simple de supprimer le contenu du fichier service-perfdata aprés il y en a d'autre

Le problème est que l'on ne perd aucune donnée car ton script process-service-perfdata est fait pour recreer le fichier avant d'ecrire s'il n'existe pas. Moi de mon coté je n'ai aucun problème.

juste avant de lire, je move le fichier vers un fichier du meme nom+_read. Des que la commande de perfdata est lancée elle recreer mon fichier. mon move lui normalement ne fait qu'un changement d'adresse. Le nouveau fichier service perfdata se fera avaler de la meme facon 10 s plus tard.

Je ne vois pas ou je perd des données. Je peux te dire que j'ai deja pas mal testé. je ne perd normalement pas de données.

je viens de modifier. Je viens de mettre move a la place de copy. Cela devrait améliorer les choses....

C'est vrai que sur des tres grosses archi il pouvait y avoir des petit problemes de perf...

[lindusfree]

Bonjour a tous,

Juste une petite question à Ludo31
Comment tu as fait pour installer RRDtool en dernière version ?

Install puis modification du chemin dans la conf de oreon où carrement un upgrade de l'ancien package par un rpm ?

Ca m'interresse.

Cordialement

PS : j'avais bien l'option deplacer les données .... coché
et j'ai seulement une quinzaine de graphe... avec des trous

[Ludo31]

Pour mettre la derniére version de rrdtool j'ai pris la version source (sur http://ftp.idilis.ro/mirrors/rrdtool/ par exemple) et ensuite j'ai arrangé mon fichier de config à mon systéme (Debian 4.0).
il ne faut pas oublier de mettre les binaires (rrdtool,rrdupdate,..) dans le dossier dont le chemin est celui que tu as indiqué dans oreon, et de mettre les fichiers perl de RRD au bon endroit.

PS: pour le probléme de unlink je viens d'identifier, je pense, le probléme. La fonction unlink a un petit inconvenient c'est que lorsque le fichier que l'on tente de supprimer est à ce moment ouvert par un autre processus celui-ci continue d'exister. Donc dans notre cas le fichier service-perfdata est ouvert par nagios lorsque le process ods vient supprimer le fichier ce qui a pour conséquence de supprimer le nom du fichier mais pas les données en elle-même (ce qui pose probléme car nagios crée des processus fils qui pointe vers le fichier "détruit" pour aller écrire les données de performance) d'où le probléme de perte de donnée.

je ne sais pas si je suis clair mais j'essaie de l'être en tout cas;)

[boyerf]

Ludo, j'ai fait ta modif qui fonctionne tres bien !
Juste un petit probleme... dans ods.log, j'ai cette erreur qui se repete :

1199724406 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724422 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724434 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724445 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724456 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique1199724467 - Error When removing service-perfdata file : Ioctl() inappropré pour un périphérique

Il gueule mais il remet bien le fichier à 0 sans l'effacer...

As tu ce problème ?

[Ludo31]

Non moi j'ai pas ce probléme la.
Est ce que tu as décoché l'option dans oreon pour déplacer le fichier service_perfdata aprés la lecture???

[julio]

t'as fait un patch maison ? :)

[Ludo31]

qu'est ce que tu veux dire par patch maison??

[julio]

la modif d'effacement du fichier perfdata ?

[Ludo31]

non j'ai pas fait de patch maison, juste fais la modif directement dans le fichier ods.

[WAtt]

Tu peux nous donner les modifications sur tu as faites, ca pourra servir (mais en gros c'st un patch maison les modifs :p)

[julio]

héhé ouais c'est ce que je voulais dire :)

[Ludo31]

la modification est pas trés importante:

sub movePerfDataFile($){
if (copy($_[0], $_[0]."_read")){
writeLogFile("Error When removing service-perfdata file : $!") if (!unlink($_[0]));
return(1);

remplacé par :


sub movePerfDataFile($){
if (copy($_[0], $_[0]."_read")){
writeLogFile("Error When purge service-perfdata file : $!") if (open(PERFDATA,'>'.$_[0]));# on purge le fichier perfdata
close(PERFDATA); #on referme le fichier perfdata dans tous les cas
return(1);

On ouvre le fichier perfdata en supprimant son contenu puis on le referme.:D

[jflamand]

Bonjour tout le monde,
et d'abord merci Ludo31 pour ton patch. Une petite remarque tout de même, ne faut-il pas plutot utiliser la ligne suivante :

writeLogFile("Error When purge service-perfdata file : $!") if (!open(PERFDATA,'>'.$_[0]));

plutot que :
writeLogFile("Error When purge service-perfdata file : $!") if (open(PERFDATA,'>'.$_[0]));

Sinon à chaque purge du fichier on envoi une erreur dans le fichier de Logs.

++

Julien.

[julio]

plus besoin pour la 1.4.2.3...

if (copy($_[0], $_[0]."_read")){est devenu
if (move($_[0], $_[0]."_read")){

[jflamand]

Re,

Dans la fonction movePerfDataFile (centreon 1.4.2.3) la ligne en rouge est-elle toujours utile ? Pourquoi doit-on supprimer un fichier que l'on vient de déplacer ?

sub movePerfDataFile($){
if (move($_[0], $_[0]."_read")){
writeLogFile("Error When removing service-perfdata file : $!") if (!unlink($_[0]));
return(1);
} else {
writeLogFile("Error When moving data in tmp read file : $!");
return(0);
}
}

++

Julien.

[julio]

ok, j'integre ca alors dès que possible

Cordialement,

[boyerf]

Suite à la mise à jour en 1.4.2.3 et à la re-perte de mes graphes... j'ai re-patché avec les modifs de Ludo31... et retrouvé mes graphes...

[julio]

normal je n'ai pas encore mis la modif dans la 1.4.2.3...

[hverdal]

Hi.

I have tried to read and understand this thread since this is the only sensible (I think) soulution to this problem. My problem is my "frensh". I'm not sure in which combination the code snippets will work? Can somebody interpit the above messages, and paste movePerfDataFile function complete?

I would aprisiate it.

[boyerf]

Hi.

I have tried to read and understand this thread since this is the only sensible (I think) soulution to this problem. My problem is my "frensh". I'm not sure in which combination the code snippets will work? Can somebody interpit the above messages, and paste movePerfDataFile function complete?

I would aprisiate it.

For me, the good solution is in this post : http://forum.oreon-project.org/showpost.php?p=33225&postcount=31

You must modify ods with this part of code (bakup it before) and tell us if this patch is usefull for you.

[gregorybel]

Salut, j'ai également testé la version 1.4.2.3 et ton c'est bien passé sauf pour mes graph. D'après ce post j'ai un problème semblable au autre. Si je ne fais pas la modif de ludo31 donc avec la fonction move de 1.4.2.3 mon fichier de log est rempli de :

Error When removing service-perfdata file : No such file or directory1201677096

Je suis d'accord avec lui que le fichier n'existe pas, je n'ai pas de fichier service-perfdata juste le service-perfdata.tmp mais c'est normal non?

et quand je fais la modif de ludo mon log est rempli de ca :

Error When purge service-perfdata file : Inappropriate ioctl for device1201677708.

Mais dans tous les cas, mes graph ne fonctionne plus. Bizarrement, j'ai une des graph nikel les 2 première heures de fonctionnement de la version 1.4.2.3 mais après plus rien. Est ce que les problèmes des log explique le fait que je n'ai plus de graph ou alors mon problème ce situe ailleurs? Par contre, j'ai supprimer tous les rrd et il on bien été regénéré et il ce mette bien a jour au file du temps mais le graph ne graph plus? Y'a plus d'encre dans le crayon de centreon?

@+

[Guigui2607]

Re,

Dans la fonction movePerfDataFile (centreon 1.4.2.3) la ligne en rouge est-elle toujours utile ? Pourquoi doit-on supprimer un fichier que l'on vient de déplacer ?

sub movePerfDataFile($){
if (move($_[0], $_[0]."_read")){
writeLogFile("Error When removing service-perfdata file : $!") if (!unlink($_[0]));
return(1);
} else {
writeLogFile("Error When moving data in tmp read file : $!");
return(0);
}
}

++

Julien.

Je rejoins la question de Julien, la ligne en rouge est elle toujours utile ?
Ou quelle modif est à faire pour éviter de remplir le fichier log alors que tout va bien.

Je suis passé en 1.4.2.3, mes graphs fonctionnent bien, mais mon fichier ods.log se remplit sans cesse avec "Error When removing service-perfdata file". :roll: