vdash is a terminal dashboard for a local Safe Vault and I’m looking for suggestions from all you prospective farmers. What would you like it to show?
The code is a fork of my learning Rust project (logtail) and uses the vault logfile to obtain metrics about the vault and the network. It uses the terminal to display this information using text and relatively crude graphics. The graphs will be a little crude but you can see the kind of thing it can do in this demo of tui-rs.
The current layout is shown below, but what I’d like are suggestions for what to show in each area: Status / Graphs and Timeline.
The following is a summary of contributions people have made to this topic, and some thoughts on the direction and priorities arising from that. Feel free to comment on this as well.
Status & Metrics:
Vault name [local; network]
Vault size
Traffic up /down by period (maybe steps up to logarithm to accommodate length)
Network connection info - who are the peers as a list or the number of them cf torrent detail
System info - cpu [type / %average]; mem [max / %average]
Change events; so, a note if there is a change of section
If network lost, then a summary of totals… and if reconnect becomes possible, then %uptime or some suggestion of the loss
Bandwidth used
Disk space used
What age we are
How many chunks of various kinds do we have
External IP/port
Current connections
Current clients connected
Current vaults connected
Safecoin earnings
Pending locked earnings
Changes in the consensus for PUT/SAFE price, or at least the sectional view of it
Colormap of chunks stored in the vault based on different criteria… (more)
A “vault map” of your local neighborhood or section… (more)
temporal signals (cf. “the history and what might pick up on might be interesting in having a handle on where and how a vault sits in the network… is that stable within a group or forever changing… too much change might suggest problems…” - @davidpbrownhere)
Your contributions are very helpful and lead me to identify four overall functions to provide in the short term:
A Show: impressive, shows key features, something people like to share.
Education: about running a vault and more generally about Safe
Problem Indications: anything that needs short term attention
State and Progress: summary of current status and change over time
Tuning Metrics: more detailed signals that can be used to optimise performance and resources
Why will people run a vault?
to earn Safecoin (for profit or utility)
to support the project (values based)
Who is this for and what do we think they will want?
The priority for the vdash project is to help individuals running a single vault or maybe a handful on one machine or multiple machines. Short term it’s easy for me to support multiple vaults on a single machine but I’d like to be able to support monitoring remote vaults, and think this should be possible (either by fetching their logfiles, using RPC as @mav has suggested, or some combination).
This for a single vault… or will we be able to have multiple vaults on a single IP?.. perhaps unknown atm??
Vault name [local; network]
Vault size / (used if that’s possible to know)
traffic up / down by period which perhaps steps up logarithm to accommodate the length.
Perhaps network connection info - who are the peers as a list or the number of them cf torrent detail
Perhaps system info - cpu [type / %average]; mem [max / %average]
Periodic change events; so, a note if there is a change of section… which I guess would occur over time.
If network lost, then a summary of totals… and if reconnect becomes possible, then %uptime or some suggestion of the loss.
Perhaps useful if you can list the variety of what the logfile keep record of?.. different types of message??
Lots of unknowns on “what’s possible” for now, so don’t worry about how many vaults, or how the data is obtained. Right now I’m just using logfile on the current machine and can easily extend from one to multiple vaults, and to check local disk, or use a vault API and so on, and maybe even to pull data in from remote vaults.
But for now the question is just, what would you like to see in a vault dashboard?
I think dashboards are hard to get right, as often they are used as a way to surface all available information, which can end up not really helping meet people’s needs, and often hindering them.
So I’d be tempted to think about this first from what a potential user might be trying to achieve, and what their needs are. This might help you in narrowing down, or considering different modes of operation.
So from my personal point of view, I’d probably be thinking of this mainly from the goal of earning Safecoin, and where I find myself in relation to that. So things like:
Is the vault working towards that goal ok?
How much has it earned for me, since I started it? And how much have I earned overall?
When am I likely to get paid again, and how much?
If there is something wrong with it, what was the problem, and how do I remedy it?
What can I do to improve my chances of earning more?
How does my earning compare? What is the potential if I did x/y?
How much of the resources I’ve offered are in use, and what impact is this having on my other tasks?
I’m not saying that all/any of these are achievable () but consider this a brainstorm for inspiration.
Very useful approach and suggestions Jim, thanks. And thanks to everyone who’s contributed suggestions because these are very helpful I’m terms of planning what data to collect and how to structure this in the app. And that will make new features easier to add later.
Things will start simple so I’ll be cherry picking things that are easy or most obviously of interest, and coming back for feedback.
vdash will be limited to what a terminal based dashboard can achieve using a character based display, but the advantage is that it should be easy to keep it working on Windows, Mac and Linux. And if I do create a native graphics version, I’ll have learned a lot about what is useful and how to present it.
Please continue with any comments whether it’s to add something not yet mentioned, or if you want to say or to something in particular. I will have my own opinions but it’s what you folks think that matters.
Everyone has basically covered what I would want (mostly I personally would want technical info about consumption of resources, a bit like htop) but I think in a broader sense @JimCollinson is hitting close to the target with his suggestions around safecoin info.
One widget I find extremely useful and is one of the reasons I am diehard xfce user (yes just for this one widget) is this handy unobtrusive cpu meter that shows 0.5s interval usage for 80 samples. Any time I use a computer without it I find it weirdly unsettling not seeing if the cpu is in use or not. It feels like driving blind.
From that chart I can see I have just finished compiling a binary on all 4 cores, and have one core still running a small ongoing job.
So maybe some of the unicode block elements could be handy if you wanted to try making this type of thing? Not actually requesting it, just pointing out what I find useful for dashboardy stuff.
What I held off suggesting was tracking change over time… the history and what might pick up on might be interesting in having a handle on where and how a vault sits in the network… is that stable within a group or forever changing… too much change might suggest problems… would hope perhaps a vult is settled and able to provide support rather than reorientating and catching up. Anything that makes visible what is occuring will be interesting curiousity, if not helpful.
A user sat looking at they vault, might want entertaining?..
This reminded me that the plan is to have some earnings locked until relocation, so it would be good to see what the pending locked earnings are (which is the second quoted bullet point I guess)
In his RFC @mav makes the point that logfiles are tricky and error prone to interpret, although for now they are all we have. I also think they have some advantages, being persistent and human readable so we can build on them at the same time as adding other ways to obtain info such as RPC.
So rather than relying on one mechanism I plan for vdash to start with the logfile, and also pull data in from different sources such as the vault process (e.g. by RPC), or from the device OS (e.g. disk usage and CPU load) etc.
With this in mind I’d like to find a way to address the ‘trickiness’ of vault logfiles, and for the requirements we’re developing here to feed into what those files contain.
I haven’t studied the logging code or the vault code so I’m just thinking ‘blind’ here, but what do @Maidsafe think about standardising the log messages make key metrics easy to obtain from any line, while leaving the human readable part able to be tweaked (or even localised/translated)?
For example, add a little encoding (e.g. after the “INFO” “WARN” that appears at the start of the message) to give a fine-grained category to the message. So INFO:12 for age change, INFO:14 to report the number of Elders in the section etc.
Then, any parameters can be wrapped in a way that makes them easy to parse in the code, but still easy to read as in age(Elder), or elders(4) and so on. (Or maybe $age:Elder and $elders:4` is better?)
This makes things easier to parse and allows the rest of the message to be tweaked so long as the log category and any parameters remain standardised, which can be helped using a set of macros.
If this is feasible we can start to build a vocabulary for all vault log messages, and identify anything it might be useful to add for the purposes of telemetry (by logfile or RPC).
I think structured logging is good, we can manually add identifiers, but maybe it’s better to have human readable names such as Age change etc. and have any parser grab those out into sections?
Lol, this was how I made graphics on the first computer I had (built from a kit c. 1980). I made a couple of things for a friend who was writing games in basic, with my assembly code doing animation such as a ‘lunar lander’ style scrolling landscape, or laser beams shooting at star wars Tie-fighters. I never thought I’d be doing that again . The first bitmapped graphics I did was also on that machine, a plotter library that created a bitmap in system memory (before we had pixel based displays) that was then dumped to a dot matrix printer. The kids today…
The stuff I did on that first computer made my career possible, so it is nice to be reminded of my many adventures with it.
It’s a toss up. I was keeping it short because those logfile lines are already very long. But if the prefix string was more readable, the messages themselves could be shorter - a bit more work changing them all though.
Awesome initiative. A piece of information I would like to see (and SAFE may need to add logging for it) are received changes in the consensus for PUT/SAFE price, or at least the sectional view of it.
An xyz colormap of chunks stored in the vault based on different criteria such as number of times a chunk has been requested, the age of the chunk, how much safecoin each chunk has earned, how long it’s been since the chunk was requested etc. The chunks could also be arranged on the screen by xor address, (use every even bit to make x coordinate and ever odd bit for y coordinate).
For chunks stored in your vault you have to take into account that their x and y ranges are limited by your section boundaries, so you have to pan and zoom accordingly.
But I don’t know if displaying pixels on a terminal based screen is feasible.
I like dashboards that have the ability to show all the information, but also default to the high overview which is what is most wanted by most people.
But what I hate is where dashboards do not allow finding out details information that is available. For instance one decent VPN (paid for) provider had a dashboard what showed current bandwidth being used. It was very useful for determining comms issues such as videos lagging since one glance showed if high usage was happening because of another program downloading updates or something. But they removed it and now the dashboard has little else and not useful anymore
It would be nice to have this too to show the vaults you are connected to. Different colors for chunk transfers between your vault and theirs, the age of the neighboring vaults, etc. A “vault map” of your local neighborhood or section… might be fun to make it look like radar sweep graphics.
) but consider this a brainstorm for inspiration.
or 
to something in particular. I will have my own opinions but it’s what you folks think that matters.
. The first bitmapped graphics I did was also on that machine, a plotter library that created a bitmap in system memory (before we had pixel based displays) that was then dumped to a dot matrix printer. The kids today… 