When you start really working with it, you will realize how much it is lacking.
My idea would be:
Fix the node management part (like adding, deleting, change of IP) so that in the best case a node has only to be added once in a lifetime
Fix the terrible tables to allow sorting, filtering, grouping, selection of (additional/new) columns to display like node age, hide/unhide
Add notifications/alerts like so that I don’t have to scroll endless tables to see that a node is not reachable, such information is crucial and needs to be on the top
Create a real information dashboard with all important information like current alerts, drop of scores, nodes not online etc.
Offer APIs/connections to let the community step in, for example to Promtheus/Grafana or whatever
The multinode is a nice foundation but it needs to become much more to efficiently handle and manage multiple nodes.
it is open source project you can easily add this features buy yourself or make your own suitable for you solution. At the end of all you receive payment for service you provide for storj.
Contributions to open source projects are not only limited to code contributions; bug reports, feature requests and providing feedback are also important contributions.
We do not overlook issue reports and feedback from the SNO community and always appreciate them.
I stumbled upon this project while searching for a multi-node dashboard. It’s working really well for me. It was pretty easy to set up. (I’m running it on a Ubuntu VM) It’s nice to see the stats for all my nodes in one place that is accessible from anywhere. Just wanted to say thanks for sharing this, and I hope you continue developing it.
may we have a docker build of the internal dashboard?
One doubt i have: for the grafana+prometheuis monitoring we need the dashboards to run on localhost network, like 127.0.0.1:14002, and your monitoring need the dashboards run on non-localhost. How can we deal with this?
With the WEB version of the storjdashboard, yes you have to run a nginx server which will make the information required availabe to storjdashboard using a security token which is part of the setup for the web version.
^^ however, not required on the internal dashboard
Hey! BIG THX for Your project first off all!
Is it possible to get ip’s or fqdn of monitoring server(s) from your side not to forward all the traffic to NGINX but only a specific one?
Also wanna check if u have any plans about telegram/discord notification?
another thing- may be its a good idea to give storj operators donation possibilities (in storj coins!) to speed up or support your project
Yes planning a launch of L1 payment tracking - but we’re still in the testing phase of zkSync, so will move to that once we’ve established a few things with this module
Okay sweet - and yea dashboard is 100% useful (basically replaced my need for the Storj one except to double check some things).
Some points I wanted to ask/bring up/suggest after using it for a while:
The monthly data area (daily ingress/egress/$ breakdown) gets pretty long toward the end of the month. Maybe make it show the latest 5 days, and the rest collapsed? Then have a button to expand it out to the current view (the idea is to be able to see entire overview/homepage without scrolling)
Add a new page for historical views. This would let you select the data you are interested in with a dropdown (monthly ingress/egress, payouts, total storage, audits/suspension/online time) in a nice graph. It would only have 1 graph and you can select what data to display.
2.5 Similar to above, but instead of combined data, it is node individual data
Not sure if possible, but % success for uploads, downloads, etc (if yes, this would also be viewable in historical way as per 2 + 2.5).
Alert for when payment goes out (not sure if current ZKsync version has this since I don’t use ZK sync - if it does then ignore this statement as it’ll be rolled out for L1 as well later?)
Just my thoughts/suggestions though - what you have is great already!
I appreciate the effort put into creating this new dashboard for SNO. However, I have some concerns regarding its architecture. It seems that the dashboard collectors require additional configuration and software installation from the SNO’s end. This setup could be streamlined for a more user-friendly experience.
I’m curious as to why the use of API, similar to the official multinode dashboard, was not considered for this project. Utilizing the API from the node dashboard could potentially simplify the process, eliminating the need for extra configuration and installation, and making it more accessible for SNOs.
