Nouvelle donne pour la métrologie ?
J’avais rédigé l’année dernière un article sur les nouvelles approches apparaissant dans la gestion des logs. Je vais continuer dans cet article ce qui est en train de devenir une série sur les nouvelles approches de la supervision avec la métrologie.
Jusqu’à maintenant, un outil règne en maître quand il s’agit de stocker et grapher les données de performance issues de la collecte Nagios (et autres) : RRDTool. Certes, RRDTool est un excellent logiciel qui nous a rendu (et continue de nous rendre) de loyaux services. Pourtant, ceux qui l’utilisent au quotidien pourront peut-être souscrire avec moi aux quelques griefs qui vont suivre:
- Le lissage des données dans le temps. Afin d’être efficient et de ne pas exploser votre capacité disque, RRD est basé sur un principe qui fait que plus vos données sont anciennes, plus elles sont « imprécises ».
- RRDTool n’est pas toujours pratique. Difficile en effet de copier des données d’une base vers une autre, difficile encore de « scaler » une solution à bases de RRDTool et enfin difficile d’envisager une architecture de haute disponibilité avec lui.
- La commande rrdgraph est vraiment « ésotérique » dans son paramétrage. Essayez de composer un graphique from scratch avec et vous verrez de quoi je parle.
- Même si certains outils permettent de contourner ce point, les graphes sont plats. Pas de zoom, pas de valeur exacte d’un point au survol de la souris.
C’est dans ce contexte que je souhaite vous présenter quelques nouveaux outils, nouvelles briques qui pourraient bien permettre d’envisager d’aller plus loin dans le traitement de vos données de performance et vous permettre « d’exploser » les limites exposées ci-dessus.
Graphite
La solution qui sort du lot en ce domaine en ce moment s’appelle Graphite. C’est à la fois un moteur de stockage des données de performance et un frontend de visualisation de celle-ci. Si vous avez suivi, il n’y a donc pas de collecte avec Graphite 😉
C’est plutôt bien fait; moteur Python et frontend Django et le projet arrive tranquillement en version 1.0. Shinken, depuis sa version 1.0 permet notamment d’envoyer ses données de performance vers celui-ci. Il existe un équivalent (que je n’ai pas testé) pour Nagios. Il est aussi possible de venir interroger des valeurs stockées par Graphite depuis Nagios avec des scripts comme celui-ci.
Graphene et autres pour Graphite
Et pour compléter le tableaux, des interfaces plutôt novatrices font leur apparition comme Graphene. Aller jeter un œil sur la doc de Graphite pour vois la liste grandissante des outils qui peuvent fonctionner avec.
Canopsis
La deuxième solution, encore jeune certes sur bien des points mais utilisable pour créer des tableaux de bord de métriques est Canopsis. Les graphiques générés par celle-ci sont certainement les plus « user friendly » avec possibilités de zoom, de superposition de données… Y a encore du boulot mais c’est prometteur.
OpenTSDB
Si vous avez vraiment beaucoup de données de performance à stocker, tournez-vous vers OpenTSDB. Leur site parle de billions de points de mesure stockés (j’en frémis) et il est possible de grapher les données depuis Graphite. Il vaut mieux par contre éviter je crois leur partie frontend avec des graphes générés par Gnuplot; pas vraiment ce que j’appelle une nouvelle approche 🙂
Collectd et consorts
Et enfin pour ceux qui pensent que collecter les données de performance avec un « Nagios like » n’a pas de sens parce que l’intervalle de collecte (5 mn habituellement) n’est pas assez court ou que les données récoltées ne sont pas assez précises, je ne pourrais que trop leur conseiller de revoir un projet dont nous avons déjà parlé sur monitoring-fr.org; à savoir Collectd. Il se trouve que celui-ci a aussi bien évolué de son côté et sait maintenant entre autres, envoyer les données collectées vers Graphite, Canopsis mais aussi (tiens donc 😉 vers MongoDB. Vous pouvez aussi jeter un œil sur Statsd.
Après ce modeste tour d’horizon des nouvelles pratiques en matière de métrologie devrait venir un nouvel article sur les nouvelles tendances à venir en matière de configuration de nos logiciels de supervision. En attendant, vous avez de quoi, si vous le souhaitez, vous passer de RRDTool. À vos consoles !
5 Comments
Trackbacks/Pingbacks
- Nono’s Vrac 55 (Dédié à Sebsauvage) « m0le'o'blog - [...] Quelques outils pour la visualisation de vos données de monitoring. [...]
- Bases de données de séries chronologiques » josDBlog - […] & StatsD: Le tandem de choix pour vos métriques Measure Anything, Measure Everything Nouvelle donne pour la…
Leave a Comment
Vous devez être connecté pour publier un commentaire.
Licence
Sauf mention spéciale, le contenu de ce site est distribué sous licence Creative Commons version BY 3.0.
Merci !
Ce serait peut-être intéressant de définir le vocabulaire de base :
– métrologie (sous-ensemble de la supervision? valeurs numériques vs. OK/WARNING/CRITICAL ?)
– hypervision vs. supervision
– …
C’est difficile a trouver dans les livres français « de référence » (Jan et/ou Gabes).
C’est très juste et cela devrait même faire l’objet d’une page sur monitoring-fr.org tant certains termes regroupent des conceptions bien différentes des choses. En attendant ce jour où une page vocabulaire/sémantique apparaîtra, voici un essai de définition des termes :
Que chacun se sentent libres de compléter, infirmer, confirmer ces essais de définitions.
Merci pour ces essais de définitions.
>libres de compléter, infirmer, confirmer ces essais de >définitions.
Je trouve qu’ajouter un nouveau terme ne simplifie pas les choses.
Est-ce que l’hypervision n’est pas tout simplement une évolution de la supervision ?
(d’ailleurs on aurait pu traduire monitoring par surveillance).
Dire tout simplement que supervision n’est pas/plus équivalent à nagios ?
En particulier, cette définition de l’hypervision recoupe certains aspects de la définition de la supervision dans ton livre :
« il est possible de découper la supervision en actions :
– observer, découvrir et inventorier,
– contrôler, collecter et stocker,
– agréger, analyser, corréler et consolider,
– présenter, indiquer et synthétiser,
– alerter, notifier et réagir. »
En relisant cette définition, j’ai plus l’impression que l’hypervision est un sous-ensemble de la supervision, comme la métrologie.
Le schéma en 3 couches pourrait être complété par les verbes.
Au passage merci pour vos livres. Même s’ils m’ont coûté les yeux de la tête, j’espère voir les prochaines éditions sur shinken et canopsis 🙂
J’utilise un dictionnaire commun lors de mes cours de supervision pour définir quels domaines sont couverts par les termes utilisés autour de la supervision.
Ce dictionnaire est basé sur le modèle FCAPS proposé par l’ISO dans le gestion des réseaux de télécommunications :
Fault Management :
C’est la supervision dont l’objectif est de détecter un panne au plus vite pour rétablir le service au plus vite pour le client. On peut également parler de Monitoring ou de surveillance.
Configuration Management :
L’objectif est de paramétrer les équipements et de gérer la sauvegarde et la restauration de ces paramètres.
Accounting Management :
L’objectif est de collecter les indicateurs qui permettent de facturer les clients. Ces indicateurs concernent la consommation des clients. Ils sont mis à disposition des systèmes de facturation qui déterminent le montant à payer pour chaque client.
Performance Management :
L’objectif est de suivre l’évolution dans le temps des indicateurs de qualité de service pour diagnostiquer un incident ou d’utilisation des ressources pour gérer le planning de capacité. On peux également parler de métrologie
Security Management :
L’objectif est de garantir la confidentialité des données (seules les personnes ayant droit accèdent aux données), l’intégrité des données (être prévenu lorsque les données sont modifiées) et la disponibilité des données (elles sont disponibles lorsqu’on en a besoin). La traçabilité (centralisation des logs) permet d’être prévenu lorsqu’un de ces trois critères est bafoué.
Le modèle FCAPS constitue les moyens qui permettent d’administrer un réseau,une plateforme de service ou un SI.
L’objectif de l’administration plus globalement est de respecter le contrat de service signé avec le client (on parle également de SLA : Service Level Agreement).