Bonjour à tous,
J'ai une petite question existentielle.
Je développe une application open source (de sauvegarde). Cette application va posséder un dashboard avec quelques métriques (taille du pool, nombre de sauvegarde en cours, …).
Certaines de ces métriques sont de l'instantané, d'autres sont mieux sur une visualisation avec un historique.
Je vais faire un endpoint prometheus pour pouvoir les exposer à … prometheus.
La question que je me pose :
- dois-je faire mon propre stockage d'historique afin de ne pas avoir de dépendance à prometheus (et que cela reste optionnel) ? Cela signifie que je dois stocker de manière efficiente les valeurs actuelles, leur historique et ensuite pouvoir les restituer de manière efficiente également (ne pas afficher tout les points sur de longue periode)
- dois-je ne pas réinventer la roue et avoir une dépendance supplémentaire à mon projet (qui a déjà une dépendance à redis) ? Prometheus me permettant de stocker l'historique et faire des requêtes dedans.
J'avoue que je penche sur la seconde solution.
Merci de votre avis et de votre expertise ;)
# Un avis
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Contexte : j'utilise des exporters prometheus, prometheus et grafana (pour afficher les métriques du prometheus) au quotidien.
Je dirais se comporter comme un exporter classique : sur une requête tu renvoies les métriques disponibles actuellement, histoire de ne pas devoir recoder et prometheus et grafana dans ton application. Et aussi histoire de pouvoir réinjecter dans n'importe quelle autre base de données temporelles/time series database (TSDB) au besoin et n'importe quelle autre application de visualisation de données en provenance d'une base de données temporelles d'ailleurs.
De toute façon même avec un simple comportement d'exporteur, tu peux néanmoins toujours injecter dans du redis ou du mariadb par pure perversité si tu veux, et exporter en CSV avant d'afficher dans LibreOffice… :)
[^] # Re: Un avis
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Fait gaffe à pas donner d'idée tordue ; ça peut être tentant la pure perversité chez des gens.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Un autre avis (mais un peu le même)
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 2.
J'ai eu le même besoin en passant tous mes backups à Borg il y a quelques mois et utilisant déjà un Prometheus pour d'autres situations, j'ai décidé d'y ajouter un exporter pour avoir une vue rapide et un suivi d'historique sur ces sauvegardes.
Bon, comme il n'y avait pas d'exporter pour ça, j'ai codé le truc moi-même. Tu ne précises pas quel système de backup tu utilises, mais si c'est Borg, je te propose (humblement) ça.
Et si ce n'est pas Borg mais que tu veux mettre les mains un peu dans le cambouis, tu peux coder l'exporter qui va bien en te basant sur ceux existant : https://github.com/nanawel/prometheus-exphporter
[^] # Re: Un autre avis (mais un peu le même)
Posté par seraf1 . Évalué à 4.
Pour info, le node_exporter par défaut de Prometheus propose un plugin textfile_collector. Ça évite de créer un exporter complet, il suffit juste d'enregistrer les métriques dans un fichier texte dans /var/lib/node_exporter/textfile_collector/.
Très pratique pour la plupart des cas.
[^] # Re: Un autre avis (mais un peu le même)
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 1.
Ah c'est bon à savoir ça ! Je n'étais jamais tombé dessus.
[^] # Re: Un autre avis (mais un peu le même)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
C'est vrai qu'on n'y pense pas souvent et que pourtant ça fait amplement l'affaire.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Merci
Posté par phoenix (site web personnel) . Évalué à 2.
Merci de vos commentaire.
Je pense que j'ai pas été claire dans mes propos.
En faite je fabrique mon propre logiciel de sauvegarde (je ne me base donc pas sur un outil existant).
La question que je pose mais elle pourrait se poser pour d'autre type d'application, c'est en plus d'avoir un exporteur pour prometheus.
Est-ce que le dashboard que je souhaite mettre dans mon application comme celui ci :
https://woodstock.shadoware.org/about/
doit se baser sur des statistiques internes, ou sur un retour de prometheus (ce qui ferait de ce dernier une dépendance à mon projet).
Merci quand même de vos réponses que je trouve intéressante.
[^] # Re: Merci
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 2.
À mon sens ce sont 2 choses séparées :
Les 2 peuvent se retrouver sur ton dashboard, mais sûrement présentées différemment (un compteur simple pour les premières, un histogramme pour les secondes).
Dans les 2 cas, la proposition de seraf1 est pertinente : il "suffit" à ton programme d'exporter les métriques dont tu as besoin dans un fichier texte qui pourra ensuite être traité avec Prometheus.
Dans le principe, ton logiciel n'a pas à se charger de cette historisation, ou de savoir comment présenter les données. Qu'il les exporte correctement déjà, et ça permettra à un autre outil, plus spécialisé, de les traiter selon tes désirs.
Rein ne t'empêche plus tard de coder toi-même un dashboard qui réutilisera ces métriques et permettra de faire des choses très spécifiques dessus, mais il est préférable je pense de se concentrer sur l'essentiel à ce stade (c'est-à-dire la sauvegarde des données).
Dans un autre principe et si je peux me permettre, les logiciels de sauvegarde c'est comme les algos de chiffrement : on réutilise autant que possible ceux qui existent, on n'en invente pas de nouveaux :p
[^] # Re: Merci
Posté par bbo . Évalué à 2.
D'après moi, tu dis tout là. Ton logiciel, c'est pour faire… de la sauvegarde !
Stocker des métriques, faire des requêtes dessus et les afficher dans un navigateur ne me parait pas être le but d'un logiciel de sauvegarde.
Franchement, si tu te lances dans un moteur de stockage de données temporelles et dans un outil de visualisation de ces données, dans vraiment pas très longtemps tu ne seras plus en train de développer un outil de sauvegarde.
Si Prometheus et Grafana existent (entre autres, ils ont chacun des concurrents), c'est que le sujet est suffisamment compliqué pour justifier un outil dédié. Si leur doc parait compliquée, c'est peut être qu'il faut du temps pour appréhender certains concepts qui paraissent intuitivement simples mais qui, en réalité, ne le sont pas (le diable se cachant dans les détails). Concepts que tu devras de toute façon bien appréhender pour pouvoir, je te cite :
Donc, tes 2 solutions me paraissent être :
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.