Closed alrevuelta closed 2 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
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
...
}
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.
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 usingprysmv1
toprysmv2
, 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.