Announcement

Collapse
No announcement yet.

plugins graphiques et remote monitoring

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

  • plugins graphiques et remote monitoring

    Je me suis intéressé plus dernièrement aux plugins graphiques.
    J'ai même déjà écrit le plugin check_graph_users.

    Il y a juste un truc qui me dérange un peu c'est en ce qui concerne les checks en remote et les graphes.

    Les plugins check_graph_xxxxx sont intéressants pour ce qui est des checks qui peuvent se faire sur les différents hosts (remote) mais uniquement au départ du serveur de monitoring. Mais qu'en est-il des checks qui se doivent d'être lancés sur les hosts (je veux parler de plugins tels que check_disk, check_load, check_log, check_procs, check_users etc) ?

    L'approche la plus évidente serait d'écrire les check_graph_xxxx en utilisant snmp, mais il faut bien reconnaitre que souvent snmp est oublié pour des raisons de sécurité évidentes. De plus, il faut une sérieuse connaissance de SNMP et des MIBs.

    Pour celà il faut savoir que Ethan Galdstad a prévu que le résultat des checks soient suivis d'un pipe (|) avec les datapoints collectés lors du check.

    Je m'explique par un exemple :

    Code:
    myhostname:/usr/local/nagios/libexec# ./check_load -w 1,1,1 -c 2,2,2
    OK - load average: 0.23, 0.07,0.02|load1=0.230000;1.000000;2.000000;0.000000 load5=0.070000;1.000000;2.000000;0.000000 load15=0.020000;1.000000;2.000000;0.000000
    Ce qui sera affiché par le CGI de Nagios sera "OK - load average: 0.23, 0.07,0.02", tout ce qui se trouve derrière le pipe (load1=0.230000;1.000000;2.000000;0.000000 load5=0.070000;1.000000;2.000000;0.000000 load15=0.020000;1.000000;2.000000;0.000000) sert pour les gens qui veulent traiter les infos récoltées.

    Vu que Oreon utilise pour une bonne part des bases de données, il me semble intéressant de sauver tous ces datapoints dans une table et d'utiliser le contenu de cette table pour générer les graphes, plutôt que de collecter les datapoints dans les bases RRD qui, à moins d'un backup ne sont pas sauvés. Un avantage d'Oreon est qu'il peut sauver toute la base , donc datapoints inclus.

    Celà résoudrait aussi le problème de la récolte des données pour ces checks qui doivent tourner en local sur le host monitoré.

    Des réactions ?
    Hopeithelps,

    Chris

  • #2
    t trop intelligent pour moi touuuuuaaaaa :lol:

    je comprend pas tout mais ca a l air une trés bonne idée :wink:
    Intel(R) Xeon(TM) CPU 3.4GHz - MemTotal : 1034476 kB
    Centreon 2.4.1 - Nagios 3.2.1 - Nagios Plugins 1.4.15 - Manubulon Plugins tuné
    Fedora Core 5 - 2.6.20-1.2320

    Comment


    • #3
      Bonjour,

      Pour celà il faut savoir que Ethan Galdstad a prévu que le résultat des checks soient suivis d'un pipe (|) avec les datapoints collectés lors du check
      Ceci est utilisable avec perfparse. Il fait exactement tout ce que tu dis. Cependant, il n'est pas intégré à l'interface de monitoring d'Oreon mais à celle de Nagios.

      Cordialement.

      Comment


      • #4
        j'ai essayé perfparse pendant 6 mois, et mon problème etait la taille de la base qui devenait trop grande pour mon petit serveur. je graphais une 10aines de machine et j'etais à plus d' 1go de données dans mysql. pas top....

        Comment


        • #5
          Bonjour,

          Perfparse permet de ne garder que certaines informations, durant une période configurable. Tu devrais peut être le configurer pour qu'il ne garde que les informations des 3 derniers mois.

          Cordialement.

          Comment


          • #6
            Originally posted by tango73
            j'ai essayé perfparse pendant 6 mois, et mon problème etait la taille de la base qui devenait trop grande pour mon petit serveur. je graphais une 10aines de machine et j'etais à plus d' 1go de données dans mysql. pas top....
            C'est évident que ça génère pas mal de données.
            Mais à mon avis il faudrait réfléchir à des routines dans la même idée que rrd. Faire des moyennes et utiliser un système de step qui permettrait de réduire considérablement la taille de la base tout en gardant une bonne cohérence dans les données.

            Imaginons qu'on fasse un check ping toutes les minutes sur un host.
            On pourrait imaginer de faire la moyenne ou encore de prendre le temps de réponse le plus élevé sur les 5 dernières minutes, ce qui réduirait la table de 4 records dans la base de données sans pour autant que ce soit incohérent.
            Hopeithelps,

            Chris

            Comment

            Working...
            X