Looks great all of it. Thanks for the insight.
Most of my ideas were already covered by our speedy @BrightSilence 
However, I’d like to stress the point of visualising reputation data - as this is soo critical to any SNO - and the numbers (at least to me) are still a little fuzzy, a running-month/week/hour reputation change would be very useful, as well as the total lifetime of cause.
So now we have rolled over to a new month then there appear to be some bugs.
Particularly as it says I have used 46% of my 25TB limit for the month.
Disk space used also appears to be giving some strange numbers
A thought here…
Is the Bandwidth Remaining actually a nodes “total - already stored data” ?
This could be reasonable if a reserve for transferring all of it’s data to other nodes would be needed?
Bandwidth Remaining The amount of bandwidth available to use by the network for the remaining month.
As seen here:
https://documentation.storj.io/setup/dashboard#storage-node-dashboard-concepts
You can also add a username-password login to make more secure ti access the dashboard from a remote location
While I don’t disagree with adding a login, I think node operators should strongly consider not exposing management interfaces directly to the internet.
This is probably not UI related, but sure is UX related and also a general interest; I’d like some way of finding out how many neighbours are in my IP/subnet group, so I can tell if I’ll get the full potential of the subnet, or if I am sharing it with 28 others, and probably should look elsewhere. That information - is it available, and could it be displayed, or graphed, under satellite information?
Well that is interesting.
But you can count on people using mechanisms to keep track of their nodes’ stats like polling the API every couple minutes and store the output in for example prometheus.
So you better find a good way to deal with a lot of requests because just relying on people to be “friendly” and not refresh stats will not work, especially not without any information about how “often” would be acceptable.
My guess is that this is spot on; and my guess is that either the satellite, or its SNO’s will create the dashboards that the SNO’s requires/imagines, because they will be created somehow.
My guess is, that the cheapest way is for the Satellite to maintain a streaming set of data, that can computationnaly cheap be downloaded by an SNO for use, in stead of being produced on demand by the SNO. The same dataset can then be used for dashboards etc on the Satellite operators panels towards itself or the SNO’s or uplinks as well. Generate once, cache, consume cheaply and as often as wished.
I think adding a limitation to the amount of refreshes to the dashboard would lessen the load. Ex: 1 refresh every X mins
I have a suggestion I am working on but it needs more work
Refreshing the dashboard requests info to the satellites? I thought it was a local server.
Sync’ing frequency is managed with config.yaml parameters.
# maximum duration to wait before requesting data
nodestats.max-sleep: 15m0s
# how often to sync reputation
nodestats.reputation-sync: 0h10m0s
# how often to sync storage
nodestats.storage-sync: 0h10m0sIf this truly is the case then we need some APIs we can use to request data from the local node only. I have monitoring on all of my nodes that pulls their dashboard APIs every minute so I can graph traffic over time, alert on low audit/uptime scores, etc. This is the kind of thing that node operators are going to do to track the health of their nodes whether or not it is “recommended” to do so.
Thought of something else. Now that the online offline indicator is a bit slow to update it would be really nice if the dashboard could show whether the external address and port are addressable from the outside and whether the identity is signed correctly. This would catch 99% of user errors during setup or later updates. I don’t think it’s necessary to show these elements when everything is fine, but adding an error when one of the two isn’t correct would help a lot.