NGraph - Testers

Le tester se charge d'abord de récolter les données, via des plugins de collection.  J'ai déjà mis au point deux plugins, qui attendent de lire un format proche :

• nagiosserv.rb : comme son nom l'indique, il lit les données de performance exportées par Nagios (voir la page de garde pour le modèle à utiliser) ; il renvoie des objets NagiosServiceData,
• genfile.rb : plus générique, ce plugin s'initialise, puis signale des démons ou exécute des scripts avant de lire les données dans des fichiers textes ; il renvoie des objets GenericServiceData qui sont, en ce moment, strictement identiques aux objets utilisés pour Nagios ci-dessus.

Ensuite, l'analyse de donnée et son stockga dans des RRDs est géreé par des testers.  Voici la liste des plugins que j'utilse actuellement dans ce but :

• enviro.rb : un plugin qui analyse le résultat de l'interrogation SNMP d'une sonde de température ; c'est un bon exemple à avoir sous les yeux pour comprendre les instructions plus bas,
• ping.rb : un testeur des résultats d'un plugin de ping ; un autre exemple à garder en vue,
• bw.rb : un analyseur de bande passante, qui lit le résultat d'un meta-plugin rapportant plusieurs informations,
• cpu.rb : un plugin simple, interprétant des données SNMP sur l'utilisation CPU,
• load.rb : une analyse du load average des serveurs Unix,
• nat.rb : interprète des informations sur le NAT réalisé sur le firewall,
• ntp.rb : analyse la synchronisation de l'horloge via NTP,
• snmp.rb : un gros plugin basé sur un meta-plugin Nagios qui sort diverses informations par SNMP en vrac,
• incomingfeed.rb : écrit pour surveiller les feeds entrant d'un serveur de news INN, en interprétant des données lues dans les logs (requiert un script spécifique lancé par syslog et un patch contre INN,
• newsfeed.rb : le pendant du précédent, utilisé pour analyser les feeds sortants (requiert le script précédent pour l'analyse des logs, mais pas de patch, au moins),
• spool.rb : ce programme-ci base l'analyse sur les articles stockés, et la hiérarchie dans laquelle ils sont postés ; il faut définir un feed et exécuter périodiquement un autre script pour produire les données.

Fonctionnement des plugins collecteurs

Ce sont à la base les objets les plus simples, qui doivent implémenter la classe Collecter (qui mixe Enumerable.  Ils sont instanciés un par un, ce qui permet de préparer le terrain si requis dans la méthode initialize.  Ensuite, la boucle priniciale itère via la méthode each, attendant de revecoir une classe ServiceData, ou quelque chose d'approchant (qui possède la propriété short pour écrire dans les logs un identifiant court, les propriétés host et time si les plugins ne sous-classent pas la méthode rrdname).

Anatomie des plugins

Au chargement du tester, chaque descendant de Tester est instancié une seule et unique fois.  Il sont placés dans une liste, ordonnée par la propriété order de chaque objet (999 par défaut)

Ensuite, le tester itère sur les collecteurs pour essayer d'enregistrer les données via la méthode register(nd) de chaque plugin, avec un itérateur, qui doit être exécuté (yield) avec pour paramère une clé (id, cfr plus bas).  Dès qu'un plugin prend en chage une ligne de données, cele-ci est détruite pour passer à la suite, d'où l'importance de l'ordre d'évaluation.

L'objet qui a enregistré une ligne va également être interrogé pour chaque clé via la méthode rrdname(nd, id) pour donner le nom qui servira a créer une base de données rrd  cette méthode est optionnelle, renvoyant par défaut "#{host.normalize}_#{id.to_s.normalize}" (normalize étant une fonction qui supprime les caractères hors de l'alphnumérique, du point, et du tiret, puis passe tout en minuscules).  Une extension .rrd est rajoutée automatiquement, ainsi que le nom du répertoire.

Le plugin est à nouveau interrogé via la méthode initrrdstruct(rrd, id).  L'objet rrd (de type RRDStruct) prend en charge une méthode addds(name, type[, heartbeat][, min][, max]) qui génère une datasource du nom indiqué, d'un des types reconnus rrdtool, sous forme de symboles (sont supportés :GAUGE, :COUNTER, :DERIVE et :ABSOLUTE).  Il est également possible de changer à ce moment les paramètres des archives (RRA), mais c'est peu utile.  Par défaut, une archive est générée pour la journée, la semaine, le mois et l'année en cours.  A noter que l'objet RRDStruct représente une unique base de données rrd.  Deux plugins distincts peuvent le remplir, mais ils doivent impérativement renvoyer la même structure via addds !

Finalement, les plugins sont sollicités avec la méthode getdata(rrd, nd, id), mettant en correspondance l'objet RRDStruct, l'objet ServiceData et l'identifiant.  Ici, une méthode de rrd doit être appelée au moins une fois : addtime(time), qui ajoute un moment de mesure et renvoie une hash table, avec pour clé toutes les valeurs de la base de données (dont le nom vient du addds plus haut), initialisées à 'U' (inconnu).  Ensuite, le tout est d'assigner les valeurs dans cette table de hachage.

Il est également utile de savoir que l'objet RRDStruct peut être itéré, et qu'il renvoie en paramètres du bloc les moments qui ont été ajoutés via addtime, et la table de valeurs correspondante.

Graphiquement, cela donne :

 

(Cliquer sur les images pour agrandir)