Cet article a pour but de présenter le fonctionnement des bases RRD (Round Robin Database) utilisées par rrdtool. Ce n'est en aucun cas un cours détaillé sur leur architecture ou autre, mais plutôt une mise en exemple de leur création et leur modification.
Si vous êtes curieux ou que vous voulez parfaire votre connaissance, je vous invite à parcourir le site de rrdtool qui présentera la chose bien mieux que moi : http://oss.oetiker.ch/rrdtool/

Avant toute chose, je tiens a préciser que les bases Round Robin sont assez restreintes en terme de modification après création, puisqu'un réagencement de la base entraine généralement la perte des données. Je vous encourage donc a bien réfléchir quant à leur contenu avant de les passer en prod, pour ne pas avoir de mauvaises surprises.

Le contenu d'une base RRD

 
Toutes les bases utilisées par rrdtool contiennent au moins deux choses :

• Une source de données (DS)
• Une ou plusieurs archives Round-Robin (RRA)

Celles-ci sont en nombre variables, suivant l'utilisation, mais une source de données est toujours liée à au moins une archive Round-Robin.
À cela, nous pouvons rajouter les intervalles de stockage (puisqu'une base rrd est indexée suivant un paramètre temporel uniquement) ainsi que la date de début d'enregistrement.
 

La création d'une base RRD

 
La syntaxe de création est élementaire :
rrdtool create base.rrd\
DS:item1:COUNTER:600:U:U\
RRA:AVERAGE:0.5:1:200
Cet exemple (pas recherché je vous l'accorde) crée une base appelée base.rrd contenant une source de données item1 dont la mise a jour entre chaque élément est d'au maximum 600 secondes (passé ce délai, le contenu passe a *UNKNOWN*. Cette source n'est par bornée, et on lui associe un champ de moyenne, contenant au maximum 200 enregistrements de la valeur du heartbeat (par défaut 300).

Je vais donc détailler le fonctionnement de cette création, avec un exemple plus concret, par exemple pouvant servir à stocker les débits d'une carte réseau.

• Avant d'entrer les les DS et RRA, vous pouvez définir le step de la base, avec l'option --step. La valeur standard est 300 secondes.
  --step 300
  Ceci permet de définir l'intervalle minimum entre deux entrées dans la base en secondes
   
• --start permet de définir la date à partir de laquelle les enregistrement dans la base sont autorisés. La valeur standard vaut timestamp - 10s
  --start 1185805047
  Ceci n'autorisera que les enregistrements postérieurs au 30 juillet 2007 à 16h17:17.
   
• Il faut maintenant creer au moins une DS.
  DS:name:type:opts
  Le type peut être au choix parmis GAUGE COUNTER DERIVE ABSOLUTE. Je ne parlerai pas de COMPUTE ici, puisque trop avancé (Voyez la doc rrd pour cela).
  • GAUGE correspond a une jauge, et peut être utilisée pour stocker une température ou une occupation disque par exemple.
  • COUNTER est un compteur incrémental qui n'accepte pas d'enregistrements inférieurs a la dernière valeur entrée sauf en cas d'overflow (il se charge de déterminer l'overflow sur 32 ou 64 bits). Utile pour mesurer le flot de paquets d'une interface par exemple
  • DERIVE effectue une dérivée par rapport au dernier enregistrement effectué. Intéressant lorsqu'une jauge présente des valeurs aberrantes.
  • ABSOLUTE est un compteur particulier puisqu'il empêche les valeurs négatives

  Bref, pour plus de détails sur leur fonctionnement, voir la doc.
  Les options correspondent à heartbeat:min:max avec dans l'ordre le délai maximal entre deux enregistrements avant que le champ prenne la valeur UNKNOWN, puis la valeur minimale du champ et pour finir sa valeur maximale.

• Pour finir, il vous faut ajouter les RRA
  RRA:CF:xff:steps:rows
  • CF correspond au type d'agrégation escomptée : AVERAGE MIN MAX LAST
    Les noms sont assez parlants pour que je ne détaille pas
  • xff est un paramètre d'interpolation utilisé pour combler les trous lorsqu'on rencontre une valeur de DS a UNKNOWN. Il prend une valeur entre 0 et 1. Personellement, je n'y touche pas trop, et je laisse à 0.5, suffisant dans la majorité des cas.
  • steps correspond au nombre de valeurs prises dans la DS pour générer ce bout d'archive. Plus vulgairement, il correspond a l'intervalle de temps considéré pour une entrée dans la base (en multiple du heartbeat)
  • rows définit la capacité maximale de l'archive, en nombre de steps.

 
Avec tout cela, vous pouvez commencer à construire vos bases de données sans trop de soucis. Pensez juste à attribuer un nom unique a chaque DS, sous peine de vous faire insulter violemment par rrdcreate.

Voici donc un exemple pour monitorer les entrées/sorties d'une interface réseau
rrdtool create bdd_eth0.rrd --step 60 \
DS:b_in:DERIVE:600:U:U \
DS:b_out:DERIVE:600:U:U \
DS:p_in:DERIVE:600:U:U \
DS:b_out:DERIVE:600:U:U \
RRA:LAST:0.5:1:1440 \
RRA:AVERAGE:0.5:5:2000 \
RRA:AVERAGE:0.5:60:720
Cette base permet de stocker les débits entrants et sortants d'une interface et d'échelonner les mesures sur la journée, la semaine ou le mois.
 

Éditer la structure de la base rrd

 
Il arrive que la structure ne soit pas adaptée aux besoins, et on peut la modifier dans certains cas.
Pour ne pas faire de plagiat pur et dur de la codumentation RRD, je vous invite à aller consulter http://oss.oetiker.ch/rrdtool/doc/rrdtune.en.html pour modifier la structure et http://oss.oetiker.ch/rrdtool/doc/rrdresize.en.html pour modifier la taille d'un ou plusieurs RRA.
 

Voilà, vous savez maintenant comment créer vos bases RRD, la prochaine étape est de les remplir.