Self-monitoring reporting specs

[shortthefomo]

Summary

There is a feature that slated for development in 2.1.0 for validator self monitoring #3508

It is also wanted to have some form of data on the nodes specs and should be considered to be added or grouped with that ticket.
Namely number of CPU core, amount of RAM and disk space, possibly a indicator of free disk as well would be amazing.

Motivation

This can help the UNL list builders get some understanding of the head room the nodes they choose to add to their lists. As well as other automated tools that could then be built for node monitoring, to let operators know they may be running out of disk (a very common issue) or possibly looking to the other specs along with the sync data that is available from the VHS to report CPU/RAM possible improvements.

Solution

It could be approached something like the 255 flag ledgers in the validation stream, but I would even look at reporting it at a lower interval 1 a day (~20000 ledgers).

[mvadari]

Note: there could be an attack vector if this info is public on the network. Then potential attackers would know how hard they need to hit the network to take it down.

[shortthefomo]

Note: there could be an attack vector if this info is public on the network. Then potential attackers would know how hard they need to hit the network to take it down.

I don't fully understand this comment, are you saying that if I throw enough tx at the network I can bring it down? Has this been shown to happen before?

[bigcjat]

We could identify OS or hardware specific issues much quicker. Like the current online delete issue, is there something in common across all nodes? If that can be identified, it can be fixed appropriately and swiftly.

I think that's where @mvadari's concern is, the same data we'd use to find potential issues, bad actors could use as attack vectors. But I think the data collected for the health of the network outweighs the potential for an exploited vulnerability.

[ximinez]

If something like this is added, it must be made opt-in, that is the default setting is "off".

[bigcjat]

If something like this is added, it must be made opt-in, that is the default setting is "off".

You can always opt-out by keeping your validator anonymous. There’s no point in identifying yourself if you’re not going to disclose details required for trust anyway. Other than superficial ones.

[ximinez]

You can always opt-out by keeping your validator anonymous. There’s no point in identifying yourself if you’re not going to disclose details required for trust anyway. Other than superficial ones.

No, that's not sufficient. However unlikely, if anonymity is broken, this would give an attacker that much more information to work with. If it's not published in the first place, then it is that much harder to obtain.

[intelliot]

@lathanbritz - can you update your post to clarify that you're requesting for the ability to share certain specs publicly over the p2p network?

Note, I believe #3508 is a very different request: it allows validator operators to self-monitor their own server. The data would be written to a private log file; it would not be shared publicly.

[shortthefomo]

@intelliot yes my request was to possibly add further information on a flag ledger to possibly the flag ledger but reading all the feed back here I see the push back on it.