Time-Series Database ou Round-Robin Database ?

Centreon, que j’apprécie particulièrement, utilise comme la majorité de ses concurrents le concept des RRD pour stocker les données. Mais n’y a t’il pas une alternative pour le stockage massif de données horodatées que le tampon circulaire, créé en 1999 par Tobi Oetiker ? Je vais vous présenter un autre système qui se nomme Time-Series Database et plus particulièrement InfluxDB, mettant en oeuvre une architecture alternative et qui présente de nombreux avantages.

Avant de commencer, un petit rappel sur les RRD : il faut à la création de la série définir un intervalle de temps (step) pour le stockage des données qui ne pourra pas être changé. Si une donnée d’un step vient a manquer, elle peut être interpolée par le système. Deuxième paramètre à définir, le nombre total de données ce qui équivaut a donner la durée de stockage. Cela permet d’avoir des fichiers de taille fixe et donc de limiter l’usage sur le disque. Quand la base est pleine, les données sont simplement « recyclées » de manière circulaire, la plus récente venant effacer la plus ancienne, d’où l’appellation round-robin ou circular buffer. L’accès a ces données se fait par une interface non standard grâce à des binding pour différents langages : Perl, Pythin, Ruby, Tcl, Php, Lua ou Java. L’API est bien évidement propriétaire et n’a aucune référence connue et c’est là un problème majeur.

Les Time-series Databases (TSDB) ont été crées pour répondre au besoin de stockage de données qui changent au fil du temps, avec une influence grandissante  du fait de l’importance croissante des usages comme l’Internet des Objets (IoT) ou la surveillance d’infrastructures. La force de ces TSBD est de pouvoir manipuler de grandes quantités de données qui étoufferait un RDBMS comme MySQL. Intéressons nous à InfluxDB, un TSDB qui peut être utilisé seul ou au sein d’un ensemble appelé T.I.C.K. :

  • Telegraf : un agent qui va collecter des métriques sur une machine, extensible par un système de plugins.
  • InfluxDB : le stockage des données.
  • Chronograf : La visualisation à l’aide de graphiques ou de widgets.
  • Kapacitor : un framework pour traiter, surveiller et lancer des alertes.

Personnellement, j’utilise à la place de Chronograf un autre élément qui s’appelle Grafana, que je trouve plus souple et dont je détaillerai l’utilisation dans un autre article.

Quelles sont les principales caractéristiques de InfluxDB ? On peut les scinder en 3 parties

1 – Des performances exceptionnelles. C’est l’une des priorités de développement de cette base. Le but est de pouvoir absorber l’afflux continuel des données, qui arrivent par des requêtes HTTP(S), au rythme de plusieurs milliers de mesures par seconde. C’est là une caractéristique fondamentale car l’exploitation des données est d’une priorité relative bien plus basse par rapport à leur prise en compte. On ne rafraîchit un graphique au mieux d’une fois par seconde.

2 – Un langage de requêtes ressemblant à SQL, qui va rapprocher l’administrateur ou le développeur d’un domaine connu. Attention cependant, l’organisation des données est complètement différente, ce n’est pas une structure avec des tables / colonnes et clefs primaires.
Par exemple, la requête qui me permet de tracer une courbe de la température ressemble à cela :

SELECT mean(temp_ext) FROM "data" WHERE time() >= 3m GROUP BY time(5d)

Un autre exemple plus complexe pour récupérer les données d’un trafic réseau entrant et sortant :

SELECT derivative(mean("bytes_recv"), 1s) AS "In", derivative(mean("bytes_sent"), 1s) *-1 AS "Out" FROM "autogen"."net" WHERE ("host" = 'sarah' AND "interface" = 'enp2s0') AND $timeFilter GROUP BY time($__interval) fill(null)

3 – Péremption et Downsampling : gérer des millions de mesures nécessite un système qui va permettre d’en limiter l’historique, en leur fixant une limite d’âge. Chaque série dans InfluxDB peut avoir une péremption, fixée individuellement ou de manière globale. Cela permet de limiter l’usage sur le système de stockage. Mais pour ne pas perdre ces données périmées, il est possible de définir une ou plusieurs règles de downsampling. Je peux ainsi définir que les températures plus vieilles que 30 jours seront reversées dans une nouvelle série qui contiendra les moyennes sur 1 semaine, avant d’être supprimées. Ce système très puissant supporte bien évidemment un enchaînement en cascade, pour conserver au mieux l’historique des mesures.

Enfin, InfluxDB permet le clustering, chose relativement importante dans les S.I. complexes et sécurisés.

Pour entrer des données, il est possible d’utiliser plusieurs protocoles différents :

  • protocole CollectD (UDP), qui est un démon  de collecte de données bien implanté dans le monde Unix.
  • protocole Graphite (UDP), logiciel qui implémente une TSDB similaire à InfluxDB et créé les graphes associés. Il est ainsi possible d’utiliser les plugins Graphite sur InfluxDB.
  • protocole OpenTSDB (HTTP), une initiative Open Source de TSDB s’appuyant sur HBase, intéressante mais moins complète, moins performante et sans l’environnement TICK.
  • protocole Prometheus (HTTP), le système de monitoring développé à l’origine pour SoundCloud et similaire à TICK.
  • protocole HTTP API, qui est le plus universel et facilement utilisable en développement (PhP, Perl, etc…), soit avec des bibliothèques, soit directement avec Curl par exemple.

En conclusion, InfluxDB est l’une des toutes meilleures TSDB disponibles, utilisable gratuitement (le clustering est uniquement compris dans la version commerciale) et avec une grande compatibilité avec l’existant. Personnellement, je l’utilise pour ma domotique (relevés des températures et de la consommation électrique, monitoring des serveurs et du réseau) avec succès depuis quelques années, complété par Grafana pour ce qui est des graphiques (je vais certainement faire un article sur ce fabuleux logiciel plus tard). Le langage de requête est puissant, les performances sont impressionnantes et le développement toujours aussi actif, comme l’a prouvé très récemment l’ajout des index TSI. Il ne reste plus qu’à convaincre Centreon de remplacer le vieillissant RRD par InfluxDB !

Ce contenu a été publié dans Administration, Logiciel de supervision, Logiciel libre, avec comme mot(s)-clé(s) , , . Vous pouvez le mettre en favoris avec ce permalien.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *