Announcement

Collapse
No announcement yet.

Probléme ODS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Probléme ODS

    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
    Intel(R) Xeon(TM) CPU 3.00GHz - MemTotal : 1036640 kB / Debian 4.0 - 2.6.18-5-686
    Nagios 2.10 - Centreon 1.4.1 - Nagios Plugins 1.4.11
    220 Hosts - 1500 Services

  • #2
    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 ?
    Julien Mathis
    Centreon Project Leader
    www.merethis.com |

    Comment


    • #3
      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.
      Intel(R) Xeon(TM) CPU 3.00GHz - MemTotal : 1036640 kB / Debian 4.0 - 2.6.18-5-686
      Nagios 2.10 - Centreon 1.4.1 - Nagios Plugins 1.4.11
      220 Hosts - 1500 Services

      Comment


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

        ca change koi en fait ?
        Julien Mathis
        Centreon Project Leader
        www.merethis.com |

        Comment


        • #5
          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 ! ) 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
          Intel(R) Xeon(TM) CPU 3.00GHz - MemTotal : 1036640 kB / Debian 4.0 - 2.6.18-5-686
          Nagios 2.10 - Centreon 1.4.1 - Nagios Plugins 1.4.11
          220 Hosts - 1500 Services

          Comment


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


            Jean
            Auteur de Shinken, outil de supervision compatible avec Nagios et orientée supervision distribuée hautement disponible et mulitplateforme.

            Comment


            • #7
              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
              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

              Comment


              • #8
                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

                Comment


                • #9
                  attend la 1.4.2.2 stp ca va pas tarder... on a une coquille
                  Julien Mathis
                  Centreon Project Leader
                  www.merethis.com |

                  Comment


                  • #10
                    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!!
                    Intel(R) Xeon(TM) CPU 3.00GHz - MemTotal : 1036640 kB / Debian 4.0 - 2.6.18-5-686
                    Nagios 2.10 - Centreon 1.4.1 - Nagios Plugins 1.4.11
                    220 Hosts - 1500 Services

                    Comment


                    • #11
                      Originally posted by julio View Post
                      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

                      Comment


                      • #12
                        C'est inclu dans la 1.4.2.2
                        Julien Mathis
                        Centreon Project Leader
                        www.merethis.com |

                        Comment


                        • #13
                          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é.
                          Intel(R) Xeon(TM) CPU 3.00GHz - MemTotal : 1036640 kB / Debian 4.0 - 2.6.18-5-686
                          Nagios 2.10 - Centreon 1.4.1 - Nagios Plugins 1.4.11
                          220 Hosts - 1500 Services

                          Comment


                          • #14
                            he je me disais aussi
                            Julien Mathis
                            Centreon Project Leader
                            www.merethis.com |

                            Comment


                            • #15
                              Originally posted by julio View Post
                              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 :
                              Code:
                              ########################################
                              # Move perfdata file to tmp file 
                              ########################################
                              
                              sub movePerfDataFile($){
                              	if (copy($_[0], $_[0]."_read")){
                              		writeLogFile("Error When removing service-perfdata file : $!") [B]if (!unlink($_[0]));[/B]
                              		return(1);
                              Et effectivement, mon fichier perfdata-service.log est régulierement effacé...

                              Comment

                              Working...
                              X