Un outil pour en tuer plein ? exploration / monitoring

Tools
1

On a trop d’outils dans la catégorie “exploration/monitoring” et ça devient franchement difficile de trouver les infos. Je vous propose cette analyse :

Catégories

On distingue plusieurs catégories de logiciels :

  • outils dans lesquel on fait des actions / saisit une clé / signe des transactions
    • ceux grand public (Ğecko/Ğinkgo/Cesium/Ğ1companion/Tikka) :right_arrow: je ne parle pas de ceux là, ils ont un public large et la concurrence est discutable mais peut avoir un sens
    • ceux pour un public spécifique (Ğ1cli/Duniter Portal) :right_arrow: il y a un sujet aussi mais c’est pour une autre fois
  • outils dans lesquels on ne fait que consulter / explorer / observer des données
    • outils grand public (Carte Monnaie Libre / Site Monnaie Libre)
    • outil public spécifique (Ǧ1data/DuniterPanel/Ğ1monit/Télémétrie/ceci…) :backhand_index_pointing_left: c’est le sujet ici.

Choses à explorer

Je mets en vrac les informations auxquelles on veut avoir accès :

  • état des réseaux Ğ1/Ğtest
    • noeuds duniter p2p + version
    • endpoints duniter rpc
    • noeuds/endpoints dunipod (remplace squid) + version
    • réseau forgeron
      • identités forgeron
      • statut forgeron
      • entrées / sorties forgeron
      • toile forgeron
      • nombre de blocs / dernier bloc calculé
  • état de la toile de confiance (invitations / identités / certifications)
  • données hors chaîne

Comment accéder à l’info

Actuellement ces outils doivent hardcoder des endpoints et faire des découverte réseau. Mais aujourd’hui on a Dunipod qui pourrait tout à fait indexer ces données et les rendre disponibles via son api. Ainsi, un explorateur pourrait tout avoir via un unique endpoint graphql, sans avoir à combiner plusieurs api rpc/graphql…

On séparerait donc le travail en deux :

  • :one: la collection des données qui se ferait coté Dunipod
  • :two: la présentation des données qui se ferait côté front sans autre logique que des appels graphql

Est-ce que ça te parle @elois ? Est-ce que ça te semble une bonne façon de distribuer les responsabilités ? Il faudrait déjà faire un front qui rend visible ce qui est déjà disponible dans Dunipod, cartographier ce qu’il nous manque, et ajouter les infos aux modules d’indexation.

On pourrait se contenter d’avoir seulement deux ou trois nœuds Dunipod équipés du module de scan réseau, suivi des derniers blocs… Pas besoin de plus pour du monitoring simple.

[edit] aux dernières nouvelles on pourrait découpler exploration / monitoring :

2

Dunipod indexe déjà toutes ses données, mais selon un modèle qui trust un nœud Duniter dédié.

Dunipod n’a pas vocation à scanner les réseaux RPC ou P2P de Duniter. Il a déjà beaucoup de responsabilités, et cela apporterait beaucoup de complexité supplémentaire pour peu de bénéfices.

C’est à des outils tiers de scanner les réseaux RPC et P2P de Duniter, ainsi que le réseau Dunipod d’ailleurs.

3

Est-ce que cet “outil tiers” pourrait être un plugin de Dunipod qui injecte les données dans la même base, avec comme but de tout avoir dans un endpoint unique ?

4

Les fronts doivent quand même scanner eux-mêmes le réseau dans tous les cas. Cela fait déjà partie du projet du front g1data de rendre visible ce qui est déjà disponible dans Dunipod, mais il doit quand même scanner le réseau.

Et certaines choses n’ont pas vraiment de sens pour un indexeur comme Dunipod. Par exemple, si je voulais ajouter la vue des forks à g1data, je requêterais directement les RPC Duniter.

Pardon, je n’ai pas compris le besoin.

Si c’est pour ajouter des données on-chain qui ne sont pas encore indexées, oui, on peut ajouter ce dont on a besoin dans dunipod-onchain.

Si c’est pour ajouter des données « réseau », comme l’état du consensus, les nœuds synchronisés, etc., alors ça me semble hors scope de Dunipod.

C’est plus simple de scanner directement le réseau pour obtenir ces données depuis les outils d’exploration ou de monitoring qui en auraient besoin, surtout pour le monitoring : la source est toujours plus fiable que la copie.

Si le besoin, c’est juste « n’avoir qu’un seul endpoint à requêter », ça me semble être une mauvaise idée.