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 :
- L’interface. Les graphiques sont plus dynamiques, ce n’est plus une simple image généré à chaque fois.
- 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 :
# Retour sur InfluxDB
Posté par Ririsoft . É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.
[^] # Re: Retour sur InfluxDB
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
On est en train de déployer du InfluxDb pour un client. A noter que la version distribuée de InfluxDb n'est pas libre.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Retour sur InfluxDB
Posté par kna . Évalué à 2.
Ça fonctionne avec collectd aussi.
# Et graphite ?
Posté par MrBidon . É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…
[^] # Re: Et graphite ?
Posté par flan (site web personnel) . Évalué à 3.
graphite (et ses sous-projets) me semble un peu abandonné, malheureusement. Il reste notamment planté en Python 2 (dont j'aimerais bien me débarrasser définitivement).
[^] # Re: Et graphite ?
Posté par MrBidon . Évalué à 2.
https://github.com/graphite-project/graphite-web/issues/750
Visiblement, ils ont l'air de bosser sur le sujet :)
[^] # Re: Et graphite ?
Posté par eMerzh (site web personnel) . Évalué à 4.
si vous voulez aller vers graphite, j'ai l'impression que graphite-api est probablement plus pour vous.
il serait plus simple a installé / maintenir et ne viendrais pas avec toutes les couches de rendu que peu de gens utilisent (souvent remplacé par grafana ou autre)
https://graphite-api.readthedocs.io/
[^] # Re: Et graphite ?
Posté par flan (site web personnel) . Évalué à 2.
merci pour l'info
# mauvais retour sur influx
Posté par StyMaar . É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 steph1978 . É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 Raoul Hecky (site web personnel) . Évalué à 2.
C'est pas mal aussi dans son genre: http://netdata.firehol.org/
# Caractéristiques
Posté par barmic . É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 Marotte ⛧ . Évalué à 2.
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.
RRDtool aussi.
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 scls19fr (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é
OpenTSDB (qui tourne par dessus Hadoop et HBase)
http://opentsdb.net/
http://hbase.apache.org/
Druid http://druid.io/
KairosDB (qui tourne sur Cassandra)
https://kairosdb.github.io/
Arctic (qui tourne sur MongoDB et qui permet de récupérer des DataFrames en Python Pandas par exemple)
https://github.com/manahl/arctic
kdb+ et le langage Q (inspiré de APL)
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.