Salut @HugoTrentesaux.
J’aimerais bien participer à cet outil de monitoring ou même le mettre en place entièrement si besoin.
–
I would love to participate in this monitoring tool or even set it up entirely if needed.
Salut @HugoTrentesaux.
J’aimerais bien participer à cet outil de monitoring ou même le mettre en place entièrement si besoin.
–
I would love to participate in this monitoring tool or even set it up entirely if needed.
Super ! Est-ce que tu vois comment t’y prendre pour faire une première preuve de concept ou est-ce que tu as besoin d’en discuter davantage ?
Non, je vois comment faire. Il faudra juste voir comment vérifier l’état de chaque service : un simple ping ou une requête un peu plus poussée (et qui sera surement différente pour chaque type de service) ?
En tout cas, je m’y mets
Au début un simple ping http périodique (par exemple toutes les dix minutes) et activable manuellement par l’utilisateur devrait suffire. Après on pourra ajouter des fonctionnalités comme une requête sur BMA pour obtenir le bloc courant des instances Duniter (/blockchain/current), mais une solution très basique sera déjà d’une grande aide
Merci @HugoTrentesaux pour ce topic dédié à la demande que j’avais formulée. La demande originale concernait surtout les noeuds duniter mais cela peut effectivement s’étendre aux autres services. Du coup, je copie/colle ce que j’ai mis dans le sujet original :
Voici le code source de instances.joinpeertube.org ou encore le code source de fediverse.observer qui pourraient inspirer @jnoel
J’ai commencé une ébauche de programme que vous pourrez voir ici :
https://g1-status.mithril.re/
Le code source est ici :
Pour le moment, ça ne ping l’url qu’au moment de la création et ça lui donne un statut (down/up) et une couleur (rouge/vert).
On pourrait imaginer stocker le délai de réponse et en faire un graph comme pour les mirroirs arch par exemple :
https://archlinux.org/mirrors/mithril.re/
N’hésitez pas à me donner vos conseils.
@Paidge, je ne vois ton message que maintenant, mais c’est une bonne idée. Je vois l’info de localisation sur peertube. Ca pourrait être intéressante pour nous aussi.
Super ! On pourra le mettre à l’ordre du jour de la visio développeurs.
Super, quand pourrais-je conseiller ce site dans mon petit tuto sur les nœuds : Nœud césium+ vs nœud duniter - Tutoriels - Forum Monnaie Libre
Il me semble aussi très important à ce jour d’ajouter les nœuds césium+
Salut @jnoel, désolé pour les retours tardifs, j’ai été très occupé ces derniers temps entre mon boulot et les rml16. Merci pour ton ébauche, ça permet de continuer la discussion plus facilement. Je propose cette liste en mode wiki pour identifier les besoins.
/
/blockchain/current
{version}
document/stats
node/summary
À noter que maintenant Kazou fournit une information assez intéressante sur les nœuds Duniter. On pourrait ajouter le lien.
Un autre plus en lien avec nous, pour la blockchain Ark: Delegates | ARK Blockchain Explorer
productivity c’est le uptime
Bonjour, désolé pour le délai, j’ai eu très peu de temps à consacrer à ce dév ces derniers mois.
Depuis quelques jours, j’ai un stagiaire en licence informatique qui a choisi de travailler sur g1_status durant son stage.
Je viens de mettre en ligne la dernière version qu’on a faite et qui permet de stocker l’historique des statuts, d’interroger BMA pour connaitre le dernier block d’un noeud et d’en déduire s’il est à jour ou pas par rapport aux autres.
Nous allons continuer dans les jours qui viennent à implémenter les fonctionnalités minimales & supplémentaires manquantes.
Une fois que les fonctionnalités seront codées, nous creuserons l’UI…
Super nouvelle ! C’est normal de galérer à trouver du temps, mais c’est super si le stagiaire est motivé par ce projet
En plus c’est une bonne manière de découvrir les spécificités de différents logiciels, les API, l’enjeu de décentralisation, les problèmes de la production…
S’il veut venir sur le forum, ça peut être une bonne occasion pour lui d’avoir des retours sur son travail en continu. On peut même lui trouver un binôme qui suggère des améliorations pour l’UI pour lui laisser plus de temps pour le back et l’implémentation. À voir ce qu’il préfère…
Une remarque à propos de wotwizard. Il y a :
Je pense que l’intérêt principal de cette interface de monitoring est l’API GraphQL de wotwizard puisque les clients en dépendent. Mais en même temps l’utilisateur sera plutôt concerné par l’ui. Donc il faudrait un moyen de rattacher une UI single-node à une API GraphQL (et idéalement avec des UI multi-node).
Pour Cesium+, si on cherche le nombre de documents sur par exemple :
https://g1.data.presles.fr/document/stats
on tombe sur une erreur disant « No feature for name [stats] ».
Pourtant c’est bien cette url qui est décrite dans l’API :
http://doc.e-is.pro/cesium-plus-pod/REST_API.html#overview
Vous avez une idée de comment on peut récupérer le nombre de documents ?
Je vois qu’on peut avoir l’info dans « node/stats »
Super nouvelle version ! J’ai mis à jour la capture d’écran dans le post principal. On pourrait en parler à la visio dev du 21 août au minimum. Jusqu’à quand Romain travaillera-t-il sur ce projet ? Est-ce qu’il veut qu’on prenne un moment ensemble pour parler des fonctionnalités supplémentaires ?
Son stage se termine demain malheureusement, mais le fait qu’il ait choisi ce projet parmi ceux que je lui ai présentés m’a obligé à m’y mettre… j’ai commencé la partie sur l’api graphql de wotwizartd, mais j’aurai besoin d’un petit point pour comprendre ce que tu as appelé les UI multi-nodes.