Vault Dashboard ideas please!

Some initial thoughts

  • 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
24 Likes

RAID status so we know when to replace drives?

4 Likes

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 (:joy:) but consider this a brainstorm for inspiration.

12 Likes

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 :+1: or :-1: to something in particular. I will have my own opinions but it’s what you folks think that matters.

8 Likes

I had some ideas for a vault rpc so these may be handy to have in a dashboard - Vault RPC by iancoleman · Pull Request #153 · maidsafe/rfcs · GitHub

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.

cpu_usage

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.

10 Likes

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?..

2 Likes

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).

2 Likes

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?

4 Likes

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 :roll_eyes:. 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… :rofl:

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.

4 Likes

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.

3 Likes

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.

2 Likes

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).

7 Likes

A long time ago I computed vaults (x, y) coordinates this way in Rust in https://github.com/Thierry61/vault_coordinates/blob/master/src/main.rs.

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.

3 Likes

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

5 Likes

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.

4 Likes

We’ve got a great list of suggested metrics and insightful comments on how to create a great dashboard, thank you @davidpbrown, @dirvine, @Knosis, @JimCollinson, @mav, @drehb, @dask, @jlpell and @neo. I’ve added everything mentioned to the OP, and a couple more thoughts as notes for myself arising from the comments which were very helpful.

It’s not to late to add to this list, but I also have a mini challenge to help me home in on the key areas for each of you. If you’re up for it, re-read the original post and reply with your suggestions for the following parts of the dashboard (v1).

>>> It’ll help if you copy the following into your replies and edit it: <<<

To clarify, I’m suggesting we fit two bar (or line) charts in the larger box at the top (hence Graph1 top middle, and Graph 2 top right), and asking whether these should be arranged vertically or horizontally. My disk space example is not the best, so while it’s quite nice to show disk use things as a two colour bar, I’m changing it to “eg. Number of GETs / PUTs / relayed chunks / other messages over the last hour”).

### Status Summary - top left
The five most important numeric values to list in are:

### Graph1 - top middle
Vertical/Horizontal?
Bars showing the following comparisons (eg. Number of GETs / PUTs / relayed chunks / other messages over the last hour):

### Graph2 - top right
Vertical/Horizontal?
Bars showing the following comparisons (eg. Number of GETs / PUTs / relayed chunks / other messages over the last hour):


### Timeline - across middle
The two most important values to show together along the horizontal timeline are:
3 Likes

No. 1 Relative capacity of the vault. Customise for % or Used/total bar graph or figures or both
No.2 Earnings (Total so far, last 24 hours)
No. 3 Number successful GETs and maybe unsuccessful ones with breakup like above.

Maybe the breakup could be total, last month, last week, last 24hours.

EDIT: Sorry just realise you wanted it in a special format. Its late here and if needed will redo

1 Like

bit confused that you’re now suggesting three elements at top; so, below suits just two and I’m not quite settled on what’s suggested and where… the ideal of a network map for the local section is nice for detailing number of elders and reducing detail on the main page.

Three elements perhaps obviously are [Vault; Network; and System], suggesting the state of the vault; the place in the network; and the stress on the local system.

Will elders earn significantly different to other vaults?.. that tempts suggestion of the time that it’s been as elder… and is there a way to estimate time till it becomes an elder?

Status Summary - top left

The five most important numeric values to list in are:

  • Vault name=location & size - eg /dev/sda1 500GB
  • Vault state [elder or noob or initialising; or whatever other]
  • Vault uptime
  • Network peers & location section name (could be just total sum and leave detail for the map of local section)
  • Safecoin [total (+pending)]

Graph1 - top middle?

Vertical/Horizontal?
Bars showing the following comparisons (eg disk space allocated, used):

  • Safecoin earnings over time as motivator.
  • Count down to becoming an Elder; or count up from being an Elder (if those are a real prospect for all vaults - otherwise perhaps becomes a negative tease??)

Graph2 - top right

Vertical/Horizontal?
Bars showing the following comparisons (eg disk space allocated, used):

  • Vault space used/total
  • Network throughput total upload/download
  • CPU/RAM current and ?max for process in case that is peaking on occasion??

Timeline - across middle

The two most important values to show together along the horizontal timeline are:

  • Network throughput total upload/download
    I think this more important than safecoin, as the activity perhaps will be erratic and the pattern might be more useful to encourage thinking on what resources are provided and how those are performing?

?

3 Likes

perhaps off topic but I wonder the motivation for users to not turn vaults off and on frequently.

If there was a status that is trusted and not new; so, a state between new and elder, that perhaps could encourage that vaults are not turned off.

Many vaults perhaps will be started by those who have not read the manual and understanding the importance of effort to always be connected, perhaps important… and then ontopic this dashboard could communicate that…

1 Like