migalabs / armiarma

Armiarma is a Libp2p open-network crawler with a current focus on Ethereum's CL network
https://monitoreth.io
MIT License
37 stars 13 forks source link

Feature: Keep track of peer parameters evolution #17

Closed alrevuelta closed 2 years ago

alrevuelta commented 3 years ago

This issue aims to purpose a possible new feature. Currently we just store a map PeerId->PeerMetadata with the latest metadata that we go from the peer, so that if we get new metadata for that peer (i.e. client name) we just update it, overriding what was before.

I would like to suggest to have a historical of the metadata of each peer. So if at some point we detect that peer x changed from using prysmv1 to prysmv2, we track that. I would just keep track of very few parameters, such as client/version and ip for example.

Note that this feature will make more sense once we have long lived running crawlers and persistance to db.

cortze commented 3 years ago

I like how it sounds. Once we export the peer metrics into a physical local database for each peer, we could try to track the metadata evolution (including the time of the tracked change). This might go associated with the refactoring of the src/metrics package of this branch

Updating reply: Do you think that the track of these changes should be compiled inside the metrics.Peer struct or should be implemented from the DB side? in relation to the idea of shifting the metrics/info to a DB, we could consider Badger, which supports key-value-version read-write

alrevuelta commented 3 years ago

Do you think that the track of these changes should be compiled inside the metrics.Peer struct or should be implemented from the DB side?

Good question. I initially thought it should be part of the Peer struct. Perhaps we could have some PeerSnapshot which is a "picture" of a peer at a given time. Then a Peer could be a list of PeerSnapshot(s). But of course not all fields are applicable. We could do something like:

Peer{
PeerSnapShoot[] s
..."fixed" data that is not related to the snapshot
}

And then:

PeerSnapShoot{
FirstDetected time
LastDetected time
ClientId
...
}
cortze commented 2 years ago

It seems that the lifetime of a client is not large enough to keep track of the evolution of the metrics (clients - versions). After a reboot of the client, most of the nodes regenerate their peer ID.