RRDTool a toujours ete dans Oreon, depuis la 0.1 meme.
En fait nous avons ete tout le temps convaincu du potentiel de ce moteur de graph, les changements ont résidé dans la maniere de creer/visionner les données de performance.
Le premier choix, et toujours fonctionnels, quoique nous ne le conseillons plus, est d'utiliser les plugins graphiques "check_graph". Ils renvoient des informations a Nagios (code d'erreur + output) et peuplent simultanement une base rrd physique.
La limitation est qu'il faut retaper tous les plugins existants et que dans le cas de supervision distribuée c'est assez limité car les bases rrd sont crees à l'endroit d'exécution du plugin.
Le second choix a été de créer des graphs rrd "a la volee" sur la base des metrics remontees dans perfparse (1.3.x). L'idée était bonne car nombre de plugins ont adopté ce format de retour d'informations et cela nous permet de centraliser les donnees.
La limitation vient du fait que perfparse est assez lourd a entretenir et son schema SQL offre peu de liberte.
Resultat, plusieurs secondes pour des graphs sur des periodes pas forcement enormes (et du coup qu'on veuille grapher plusieurs metrics dans le meme graph...) et dans le temps, la retention d'informations prend une place énorme.
La troisieme solution, actuelle et très performante :
Donner a l'utilisateur le choix dans sa remontee, bases rrd physiques et/ou base SQL, a partir des donnees de performances qui sont remontées.
L'interet est qu'on a des bases rrd physiques, donc tres rapides a grapher et facilement manipulables (cacti, pnp styles) et que ceux qui le desirent peuvent stocker les donnees de performance dans un nouveau modele de base de donnees (Oreon Data Storage), plus light et optimisé que perfparse afin de conserver dans le temps ses donnees, ou alors pour une exploitation exterieure (reporting...).
[^] # Re: Graphique : RRDTools ou Perfparse ?
Posté par Romain Le Merlus . En réponse à la dépêche Monitoring Oreon : sortie de la version 1.4. Évalué à 4.
En fait nous avons ete tout le temps convaincu du potentiel de ce moteur de graph, les changements ont résidé dans la maniere de creer/visionner les données de performance.
Le premier choix, et toujours fonctionnels, quoique nous ne le conseillons plus, est d'utiliser les plugins graphiques "check_graph". Ils renvoient des informations a Nagios (code d'erreur + output) et peuplent simultanement une base rrd physique.
La limitation est qu'il faut retaper tous les plugins existants et que dans le cas de supervision distribuée c'est assez limité car les bases rrd sont crees à l'endroit d'exécution du plugin.
Le second choix a été de créer des graphs rrd "a la volee" sur la base des metrics remontees dans perfparse (1.3.x). L'idée était bonne car nombre de plugins ont adopté ce format de retour d'informations et cela nous permet de centraliser les donnees.
La limitation vient du fait que perfparse est assez lourd a entretenir et son schema SQL offre peu de liberte.
Resultat, plusieurs secondes pour des graphs sur des periodes pas forcement enormes (et du coup qu'on veuille grapher plusieurs metrics dans le meme graph...) et dans le temps, la retention d'informations prend une place énorme.
La troisieme solution, actuelle et très performante :
Donner a l'utilisateur le choix dans sa remontee, bases rrd physiques et/ou base SQL, a partir des donnees de performances qui sont remontées.
L'interet est qu'on a des bases rrd physiques, donc tres rapides a grapher et facilement manipulables (cacti, pnp styles) et que ceux qui le desirent peuvent stocker les donnees de performance dans un nouveau modele de base de donnees (Oreon Data Storage), plus light et optimisé que perfparse afin de conserver dans le temps ses donnees, ou alors pour une exploitation exterieure (reporting...).
C'est mieux ? :p