Journal Base de séries temporelles

Posté par  . Licence CC By‑SA.
Étiquettes :
21
7
avr.
2017

La hauteur d’un cour d’eau, la température d’une véranda… le niveau de pression acoustique d’un carrefour passant… ou encore l’espace occupé d’un disque dur ou le temps de réponse d’un serveur, toutes ces données peuvent être exploitées intelligemment à condition d’être liées au temps.

Pour stocker ces données, un système de gestion de données relationnel est mal adapté. Il n’est pas conçu pour ça.

Après bientôt vingt années, RRDtool était devenu l’outil incontournable pour gérer ce type de données.

Afin de pouvoir stocker une quantité gigantesque de ces « séries temporelles », sur une période longue comme la vie des rats, avec RRDtool (pour faire simple) on définit une fréquence de mesure, puis des sources de données : nom, minimum, maximum… et pour ces sources de données, des règles d’archivage : garder chaque mesure pendant 24 heures, puis chaque moyenne (ou max, ou min) de 4 mesures consécutives pendant 1 mois, puis chaque moyenne de 32 mesures sur 1 ans, etc…, etc… Ainsi, la taille de la base peut être déterminée à l’avance et on a donc un fichier de taille fixe pour un ensemble de sources de données.

Malgré la robustesse et l’efficacité de RRDtool, compte tenu de son grand âge, il péche sur certains points. Les débats sur les "Time Series DBMS" ne sont pas clos et il existe plusieurs produits qui tirent leur épingle du jeu sur ce créneau.

Je suis tombé sur ce comparatif entre notamment InfluxDB et RRDtool et j’aimerais connaître vos avis sur les différentes solutions plus modernes qui peuvent avantageusement remplacer RRDtool.

Je vois deux avantages possibles apportés par InfluxDB, ou Graphite, ou d’autres approches comme ElasticSearch+Kibana, etc… ce sont :

  1. L’interface. Les graphiques sont plus dynamiques, ce n’est plus une simple image généré à chaque fois.
  2. Les performances. Pour passer à l’échelle, encaisser beaucoup d’accès concurrents, de la réplication, etc…

À la base je cherchais juste une interface moderne et user-friendly pour naviguer dans des fichiers RRD. J’ai trouvé drraw, un CGI en Perl visiblement plus maintenu (mais qui juste marche…), que je trouve tout à fait efficace (KISS). Cependant il fera fuir n’importe quel décideur pressé quand s’il voit l’interface… hum… rétro.

Même si ça pourrait très bien aller, pour lui fournir simplement un graphique par URL, pour prendre ses décisions…

Pour ceux qui ont lu jusque-là (et seulement eux), une belle nimage :

Nimage

  • # Retour sur InfluxDB

    Posté par  . Évalué à 6.

    J'utilise InfluxDB + Grafana dans un environnement professionnel (monitoring transactionnel) et personnel (monitoring serveur perso).

    Pour un usage pro c'est pas encore tout à fait mûre mais c'est en bonne voie. Par exemple le nombre de séries est limité par la mémoire sur un noeud. La dernière version améliore les choses mais il y a encore du travail à faire. Mais franchement ça s'utilise très bien en PROD pour un usage non critique. Grafana est super agréable par rapport à Cacti, RDDTool et autre solutions de monitoring.

    Pour un usage perso ça marche très très bien, notamment avec le moniteur système companion telegraf (la fameuse stack TICK de chez InfluxData).

    InfluxDB vient en complément d'ElasticSearch pour mon usage pro: InfluxDB excelle vraiment dès que tu veux jouer avec le temps (dérivée, percentile, …). ES excelle vraiment dans le grouping et la recherche par valeur. InfluxDB prend moins de place sur disque qu'ES pour les mêmes données (facteur 3 dans mon usage).

    Comme toutes les DB modernes (Mongo, Couch, Influx et autres), c'est très bien pensé pour les devops : facile à déployer, à maintenir et à monitorer.

    Non franchement dans le genre Time Series DB je recommande sincèrement d'essayer InfluxDB.

  • # Et graphite ?

    Posté par  . Évalué à 2.

    Pour ce genre de cas, j'avais repéré Graphite http://graphiteapp.org/ qui me semble plus mature que influxdb.

    Mais, je n'ai pas encore eu le temps de tester…

  • # mauvais retour sur influx

    Posté par  . Évalué à 9. Dernière modification le 08 avril 2017 à 10:39.

    Dans mon ancienne boite, des gens utilisaient influx et ils n'en n'étaient pas très contents.

    Principaux griefs:
    - très instable: pas mal de bugs, et les mises à jour apportant les correctifs entrainent souvent des régressions. Ils ont du rester très longtemps sur une vieille version malgré le fait que les plus récentes avaient des fonctionnalités dont ils avaient besoin, simplement parce-que les versions récentes avaient toutes des bugs critiques (quand tu ne peux pas remonter tes back-ups, c'est quand-même un peu chaud).
    - scalabilité pas au rendez-vous : l'un des arguments d'influx c'est de tenir super bien la charge en écriture mais les résultats n'étaient pas du tout conformes aux attentes. Mes collègues avaient du faire leur propre agrégateur maison en amont d'influx pour envoyer moins de points sinon la base ne suivait pas.

    Après, ça fait 1 an que j'ai quitté cette boite, donc Influx s'est peut-être améliorée depuis.

    Pour la petite histoire, ils se traînaient influx qui avait été introduit dans la boîte par un ancien salarié au tout début de la boite, fanboy de Go (le langage) il avait décidé d'utiliser influx parce-que c'était écrit en Go (bonjour la décision technique éclairée).

  • # drraw

    Posté par  . Évalué à 4.

    Les mêmes recherches m'ont aussi conduit vers drraw.

    Un peu brute comme interface, mais finalement est très efficace avec une bonne capacité de customisation des graphes et dashboard.

    C'est en perl donc pas mon langage de prédilection et le script est plutôt touffu avec un manque de factorisation et le HTML noyé dans le code. Mais j'ai quand même pu le mettre à ma sauce.

  • # Netdata

    Posté par  (site web personnel) . Évalué à 2.

    C'est pas mal aussi dans son genre: http://netdata.firehol.org/

  • # Caractéristiques

    Posté par  . Évalué à 3.

    Je n'ai jamais utilisé ce genre de base de données, quels sont les caractéristiques dont tu as besoin ?
    Pour moi rddtool c'est plus un buffer en anneau de ce que j'en sais, avec les commentaires au dessus je vois que Influx utilise des politiques de rétention. J'ai l'impression de voir aussi beaucoup de mélange entre les moteurs de stockages et les outils de graphings dans les commentaires.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Caractéristiques

      Posté par  . Évalué à 2.

      Pour moi rddtool c'est plus un buffer en anneau de ce que j'en sais

      C’est plus qu’un simple buffer circulaire… Je sais pas comment expliquer plus simplement que ce que j’ai déjà expliqué dans le journal. Sinon après il faudrait que tu lises http://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html pour y voir un peu plus clair.

      Influx utilise des politiques de rétention

      RRDtool aussi.

      beaucoup de mélange entre les moteurs de stockages et les outils de graphings dans les commentaires.

      Oui. En fait je voulais savoir si je pouvais conserver RRDtool comme moteur de stockage et l’utiliser avec d’autres outils pour le graphing.

      Avec toutes les réponses que j’ai obtenu il y a de quoi faire, pas mal de chose à tester, c’est cool.

  • # Quelques autres TSDB

    Posté par  (site web personnel) . Évalué à 2.

    Bonjour,

    J'avais regardé il y a quelques temps le sujet des bases de données pour séries temporelles (time series database (TSDB))

    J'avais trouvé

    mais je n'ai jamais pris le temps d'explorer ça davantage… au final j'ai stocké ce que j'avais à stocker dans une base relationnelle MySQL ou PostgreSQL mais j'ai pas des tonnes de données non plus. Pas (vraiment) besoin de ré-échantillonnage à la volée par exemple…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.