Les bases de données de séries chronologiques

La problématique des base de données en supervision

Nous avons besoin en supervision de bases de données optimisées pour le stockage d’événements et de métriques. Une particularité est le volume important qu’occupe les données prélevées sur l’ensemble d’un parc informatique par exemple toutes les minutes. Si vous prenez une vingtaine de mesures sur un serveur et que vous en avez une centaine, cela vous fait 2000 mesures à stocker toutes les minutes soit près de 3 millions de points/jour. Les bases de données relationnelles traditionnelles ont vite montré leurs limites dans ce genre d’exercice. Elles ne sont pas « designées » pour ça.

Les données stockées en supervision permettent de répondre à des besoins comme :

  • Avoir en temps réel les informations sur l’état de santé des infrastructure et des services.
  • Détecter les impacts et la cause première d’un incident ou d’une panne.
  • Calculer les SLA (disponibilité, temps de latence, etc)
  • Permettre le tuning des applications, bases de données, système d’exploitation et réseaux pour des performances maximales.
  • Faire de la planification des capacités (capacity planning).

Cette situation donne donc petit à petit naissance à un nouveau genre de bases de données; les bases de données de séries chronologiques (time series database).

Les bases de données de séries chronologiques

Ce type de base de données se fait une spécialité de stocker l’ensemble des métriques remontées par votre supervision, métrologie et nous allons le voir, peut-être même un peu plus. Elles n’ont pas vocation à devenir des bases de données généralistes comme MySQL ou autres SGBD mais se focalisent au contraire sur un certain nombre de caractéristiques.

Caractéristiques des bases de données de séries chronologiques

Voici quelques caractéristiques qu’il est souhaitable de trouver dans une base de données de séries chronologiques.

Gros volume de données

je vous en ai parlé en introduction. Un jeu de données complet remonté par la supervision pour les métriques peut rapidement compter plusieurs millions, milliards de lignes. Collecter un point de données toutes les secondes pendant un an représente 31,5 millions de lignes.

Grande quantité de données immuables

Les bases de données de séries chronologiques contiennent des données qui ne sont normalement pas modifiées après insertion. C’est typiquement le cas avec nos contrôles, sondes de supervision où chaque exécution créée de nouvelles valeurs sans toucher aux précédentes.

Première clé de tri temporelle

Les bases de données de séries chronologiques sont par concept triées chronologiquement. Les bases de données relationnelles sont prévues pour supporter toutes sortes de requêtes différentes qui peuvent être construites en fonction du type de données présentes. Ce type de fonctionnalité ajoute pas mal de traitement supplémentaire qui affecte particulièrement le stockage et les accès à celui-i. À partir du moment où vous savez que vous allez trier vos données de façon chronologique; vous pouvez construire l’outil qui va le faire de façon efficace et automatique.

Résolution des données et statistiques

Avec les données de séries chronologiques, vous avez souvent besoin de réduire la résolution pour pouvoir comprendre les données. Par exemple, si vous voulez voir l’évolution des charges de vos serveurs depuis un mois, vous n’avez probablement pas besoin de voir cette information à un intervalle (résolution) de une seconde. Vous allez plutôt rechercher des maximums, minimums, moyennes, déviations par jour ou heure en fonction des données… Vous appliquez des fonctions statistiques.

Bases de données de séries chronologiques Open Source

Jusqu’à très récemment, il n’existait pas ou peu de bases de données spécialisées pour la supervision en dehors du vénérable RRD Tool. Cependant, quiconque a utilisé un jour RRD Tool comme bases de données pour le stockage des métriques de la supervision peut témoigner de la difficulté de son exploitation au quotidien (sauvegarde, export, scalabilité). L’un des points forts de RRD Tool au niveau stockage, la taille fixe des bases est devenu au fil du temps un quasi handicap puisque celle-ci se fait au détriment de la précision des données qui sont lissées dans le temps.

Les choses changent et les bases de données que nous allons voir partagent toutes :

  • Le fait de pouvoir s’architecturer de façon industrielle et scalable.
  • Le fait d’offrir une API permettant le stockage et le requêtage basé sur des paires clés/valeur.
  • Le fait de pouvoir réaliser des opérations statistiques (moyenne, max, min…) « nativement » sur les données.
  • Le fait de pouvoir faire du lissage des données (downsampling) dans le temps mais ce n’est plus une obligation.

Whisper

Whisper est la base de données écrite pour le projet Graphite et les développeurs expliquent pourquoi ils n’ont pas utilisé RRD Tool. Whisper conserve néanmoins avec son aîné RRD Tool le fait de lisser les valeurs dans le temps. Whipser représente à mes yeux une transition entre RRD Tool et les projets qui suivent. Il est difficilement envisageable de l’utiliser sans utiliser Graphite.

OpenTSDB

Utilisé par StumbleUpon pour stocker plus de 1 milliards de points par jour, OpenTSDB utilise HBase pour le stockage des données de séries chronologiques. Dans OpenTSD, une donnée, un point est simplement constitué de :

  • Un nom de métrique.
  • Un timestamp UNIX (secondes depuis Epoch).
  • Une valeur.
  • Une série de tags (paires clés/valeurs).

C’est généralement le type de « structure » de données de ce type de base de données. Il est possible de dialoguer avec OpenTSDB par un simple protocole de type telnet ou par HTTP.

Le logiciel est également utilisable comme interface pour construire les graphiques issues des données récoltées. Cela dit, le résultat, basé sur Gnuplot, n’est pas vraiment flatteur.

Le logiciel est certainement le plus mature du lot et une version 2.0.0. RC2 vient de sortir au mois de novembre. Cette version apporte notamment une API de type REST et la capacité de stocker des données avec une précision à la milli-seconde, à l’instar de KairosDB.

KairosDB

KairosDB est un projet né des idées mises en œuvre pour OpenTSDB mais amenées vers d’autres horizons. KairosDB peut fonctionner avec HBase, mais aussi H2 ou Cassandra. C’est Cassandra le moteur recommandé pour la production. Comme OpenTSDB, KairosDB peut être utilisé comme interface pour construire les graphiques issues des données récoltées. La version 0.9.2 est sortie au mois de novembre. Difficile de vous en dire plus tant la documentation du projet est basique.

InfluxDB

InfluxDB pourrait bien représenter le Saint Graal des bases de données puisque capable de stocker des données de séries chronologiques et événements. C’est tout au moins ce qui est vendu par ce tout nouveau projet.

InfluxDB est basé sur LevelDB, la librairie clé/valeur écrite pour être rapide par Google. C’est le plus jeune des projets présentés et la version 0.4.0 vient de sortir. Il est possible d’utiliser le démon « universel » de statistiques, statsD pour envoyer des données vers InfluxDB.

Tasseo, le projet de dashboard pour Graphite est désormais compatible InfluxDB. Voilà donc une première interface disponible pour visualiser vos données.

Bases de données de séries chronologiques as a service

TempoDB est le pendant online des bases vues ci-dessus et qui a été apparemment spécialement pensée pour les environnements de supervision.

Big Data supervision ?

Ces bases de données permettent d’entrevoir des systèmes complets de supervision où le volume de données à traiter, stocker ne représente plus un frein au nombre d’indicateurs collectés. La supervision peut désormais entrer de plein pied dans l’ère du Big Data.

N’hésitez pas à commenter si vous connaissez d’autres bases de données de ce type ou si vous avez une quelconque expérience avec celles présentées.

Vus : 529
Publié par Wooster by CheckmyWebsite : 49