Outil pour surveiller des nœuds

Edit : tout ça se trouve maintenant dans un magnifique projet git.

Bonjour à tous,
j’avais fait il y a quelques temps un petit outil en Java pour surveiller les nœuds… outil jamais abouti et qui a encore un paquet d’heures de travail devant lui… surtout avec le passage aux websockets…

Du coup avec le fork en cours, j’ai décidé ce matin de faire un outil simple en shell pour surveiller des nœuds et d’éventuels forks. C’est pas optimisé, c’est du shell bash hardcore, ça se base uniquement sur du http, c’est codé à l’arrache, faut remplir un fichier à la main, mais ça marche très bien et comme les nœuds sont interrogés en parallèle, ça va très vite. Non, ça ne fait pas le café.

Pour commencer, téléchargez le script checknodes.zip (1.6 KB) et dézippez-le.

Ensuite, créez dans le même répertoire que le script un fichier nodes.txt qui ressemble à ça (en fait vous pouvez très bien copier-coller ça direct…) :

77.136.120.230:20900
77.152.31.154:20900
78.226.163.68:20900
78.242.59.220:20900
82.251.191.185:10901
83.204.199.211:20900
88.124.134.32:20900
89.84.209.173:20900
90.9.219.154:20900
91.121.157.13:10903
93.20.61.189:20900
95.130.13.155:10901
duniter-g1.p2p.legal
duniter.fabwice.com
duniter.jesuislibre.net
duniter.moul.re
duniter.normandie-libre.fr
g1a.jytou.fr:9002 !
g1b.jytou.fr:9001 !
g1.altsysnet.com:10900
g1.cgeek.fr
g1.donnadieu.fr:12901
g1.duniter.org
g1.duniter.sajm.ovh
g1.jytou.fr:9000 !
g1.monnaielibreoccitanie.org
g1.nordstrom.duniter.org
g1.presles.fr
jardin.foyerruralct.fr:20902
legacy.g1.nordstrom.duniter.org
paidge.normandie-libre.fr
remuniter.cgeek.fr:16120
ts.g1.librelois.fr

La syntaxe est simplissime : un nœud par ligne, mettez un # en début de ligne pour ignorer temporairement un nœud, et un ! en fin de ligne (séparé du nom par un espace) pour votre nœud : il apparaîtra en gras et vous saurez d’un coup d’œil s’il est sur une bonne branche ou s’il est parti en fork.

Enfin, lancez le script : ./checknodes.sh

Exemple de résultat (oui, je sais j’ai des goûts de ch***e, et alors ?) :


Autre exemple en s’en tenant aux nœud qui sont sur la branche principale :
Screenshot%20from%202019-03-28%2017-39-29
On peut voir:

  • les différentes branches avec leur numéro de bloc + le début de son hash et les nœuds sur ces blocs, tout ça bien sûr trié par ordre alphabétique,
  • les nœuds qui sont en http,
  • les nœuds en erreur à la fin,
  • un compte rendu sur l’état de la blockchain avec le nombre de forks pour les nœuds surveillés (rien ne dit que d’autres nœuds ne viennent pas mettre la pagaille ailleurs),
  • le compteur en bas représente le temps qui reste avant le prochain scan.

Vous pouvez aussi modifier en début de fichier 3 paramètres :

  • le temps d’attente entre 2 scans (en secondes),
  • les timeout pour les nœuds en https et http.

À utiliser sans modération, n’hésitez pas à faire des modifs/améliorations - à copier, redistribuer, modifier, exécuter, à vos risques et périls. Ne venez pas vous plaindre à moi si vous êtes englouti par une avalanche ! :smiley:

Exemples d’améliorations ou customisations :

  • envoyer un mail en cas de fork (et en ne conservant dans la liste que les nœuds les plus « sains » pour ne pas recevoir un mail toutes les 5 minutes),
  • pour chaque nœud, faire également un scan sur /network/peers, récupérer la liste des peers et boucler sur les peers qu’on n’a pas encore scannés, en boucle jusqu’à avoir tout scanné, ça serait assez facile à faire mais en quelques heures, mais ça serait du coup un excellent observateur du réseau tout entier à peu de frais…
  • avec ça observer également les nœuds en WebSocket…

Oui, je sais, j’ai trop d’idées et pas assez de temps pour les implémenter, comme d’hab…

8 Likes

ça pourrait ptet faire l’objet d’un dépôt sur le gitlab nan ?

J’y ai pensé mais j’ai eu la flemme… :smiley: je pense que ça va quand même se terminer comme ça… bon ça c’est fait.

1 Like

J’aurais trié les branches par ordre décroissant.
Actuellement la branche la plus avancée est au milieu entre les retardataires et les nœuds en erreur.
Ça fait pas très intuitif.

3 Likes

Comment définis-tu un nœud en erreur ?
Lorsque le nœud a un retard supérieur à la taille de la fenêtre de fork par rapport à la branche la plus avancée ?

Ah non zut, faut refaire tout le script ! :smiley:

Plus sérieusement il suffit de rajouter un -r à la ligne 88:

remplacer

        chains="`echo "$curs"|grep -v ERROR|awk '{print $1}'|sort|uniq`"

par

        chains="`echo "$curs"|grep -v ERROR|awk '{print $1}'|sort -r|uniq`"

Tout ça c’est fait aussi.

Oula non, c’est bien plus simple : un nœud en erreur est un nœud qui ne répond pas dans le timeout. C’est un script bash, il ne fait pas de calcul de résolution des forks… à noter d’ailleurs que si on a un fork qui se sépare en 2 blocs distincts mais avec le même numéro de bloc, le script n’y verra que du feu ! Comme je disais, il fait pas le café ! :smiley: le script regroupe maintenant par numéro de bloc et hash donc on voit bien les vraies branches maintenant. Mais il ne fait toujours pas le café. :stuck_out_tongue:

2 Likes

À la demande générale (ou pas), j’ai édité mon post d’origine et uploadé une nouvelle version :

  • timeout un peu moins serrés,
  • tri des branches par ordre décroissant,
  • ajout du début du hash pour chaque bloc histoire de bien repérer les forks avec le même numéro de bloc.

J’ai aussi mis à jour la liste courante des nœuds que je vois histoire d’être un peu plus exaustif.

2 Likes

Tout ça est maintenant dans un dépot gitlab.

Et vive le multipost. :smiley:

4 Likes