System status in v3

[grossmj]

I have updated the server to report the disk usage for all partitions instead of just the root partition. See https://github.com/GNS3/gns3-server/issues/1947

Now we need to reflect this in the web-ui, not sure how to display it in a meaningful way.

Maybe we can keep disk usage to show an aggregate and then list each partitions below?

Or we could completely refactor this part since some users have reported they really like the way CML shows system stats, that is pleasing to the eyes etc. do you think we should switch to similar presentation ?

[lurendrejer]

I'd go for a much more 'advanced' view. CPU usage per core. Numa statistics. All harddrives. Ethernet statistics, etc.

Having this info in the GNS3Client would be great. My users prefer the client, because console access and wireshark is iffy on the web-gui, still.

[lurendrejer]

And a small note on the web-ui, you have to open a project to be able to access the serverinfo. Is this an oversight in the design department? :)

[grossmj]

And a small note on the web-ui, you have to open a project to be able to access the serverinfo. Is this an oversight in the design department? :)

Indeed, I was thinking the same today. The system stats should be accessible from the server page.

[grossmj]

I'd go for a much more 'advanced' view.

I like the idea. The server could report more stats for this advanced view.

Having this info in the GNS3Client would be great.

We will most likely do this but our focus is currently on the server side and web-ui ;)

[lurendrejer]

I'd go for a much more 'advanced' view.

I like the idea. The server could report more stats for this advanced view.

Having this info in the GNS3Client would be great.

We will most likely do this but our focus is currently on the server side and web-ui ;)

Completely understandable - The web-UI is the way to go, I'm all for it.

[eantowne]

Personally, I think a very simple performance monitor should be the default with a more advanced view available. I prefer the second image that @grossmj posted. Not only for the simple, and clean aspect, but it also lends itself to a multi-server view better than the top image. For a more advanced view, it should be per server if you really want to get that detailed on the monitoring. Myself, I think that really detailed monitoring should be left to software that is designed for specifically that. For instance, the below is how I do my detailed monitoring. I also use cockpit sometimes.

[lurendrejer]

@eantowne @grossmj - I don't think a multi-server view is fitting in GNS3. In a monitoring tool, yes.

But having hundreds of users using hundred of GNS3-servers I would prefer to have them only see their own server stats - should they run into performance issues.

[lurendrejer]

But again, having both like @eantowne mentions would be fine for everybody. If i had to choose, I'd go for advanced only.

[eantowne]

@lurendrejer My mention for multi-server is for people like me who are running a multi-compute environment. I have projects that span 5 different computes. The bottom picture that @grossmj posted could be stacked (a row for each compute) that can be collapsed to only show a single row with the aggregate for all computes. This is the way that CML does it (which is where that screenshot came from I believe).

Basic monitoring (CPU and RAM utilization) while running projects is what I feel is necessary for general monitoring. Occasionally, the need arises for detailed monitoring, and I feel that is where the "advanced" view would come in.

[eantowne]

@lurendrejer Side note, performance for only the computes that a user has permissions for should be available. This falls into the RBAC/API side of things.

[lurendrejer]

@eantowne absolutely. My main wish would be the ability to have the advanced view, in any given way. My users often have performance issues because of CPU-latancy, they can't troubleshoot that with the current 'sparse' interface.

[grossmj]

But having hundreds of users using hundred of GNS3-servers I would prefer to have them only see their own server stats - should they run into performance issues.

Restricting the stats by users is a great idea 👍 as @eantowne mentioned this falls into the RBAC/API side of things, this will have to be done in v3.0

The bottom picture that @grossmj posted could be stacked (a row for each compute) .

Currently in the web-ui we have one row per compute.

My users often have performance issues because of CPU-latancy, they can't troubleshoot that with the current 'sparse' interface.

We should find a balance, I agree we should provide a little bit more useful stats but without going too crazy in the details, there are tools out there better suited for this.

Looks like there is a little bit more work to be done on stats so I will more it to v3.0 so we can get it right.

[lurendrejer]

@grossmj Superb. Will the disk-usage fix be implemented in 2.x still?

That is a huge problem in my end.

[grossmj]

Will the disk-usage fix be implemented in 2.x still?

Ok, maybe we could have an aggregate for now but is it useful for disk usage?

A better solution could be to list the partitions in little boxes (same style as the memory info) at the bottom.

[eantowne]

I would recommend having a detailed view available by clicking on a given server within the current "sparse" performance tracking. Aggregating disk usage is near useless in my mind, as a given compute could have multiple disks/partitions and most will have nothing to do with GNS3 performance. I would suggest providing disk usage for only partitions that have bearing, for instance primary OS partition and whatever partition(s) the GNS3 projects/images directories reside in. This would increase the complexity of gathering this data, but would also provide better/more applicable metrics.

[eantowne]

For instance, aggregating this data would be useless from a GNS3 performance monitoring perspective.

df -h
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 3.2G  2.7M  3.2G   1% /run
/dev/nvme0n1p3        1.9T   99G  1.7T   6% /
tmpfs                  16G     0   16G   0% /dev/shm
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                 4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/nvme0n1p1        497M  352M  146M  71% /boot/efi
/dev/nvme0n1p2        4.0G  2.8G  1.3G  70% /recovery
/dev/nvme1n1p1        1.9T  117G  1.7T   7% /mnt/Fast
/dev/md127            938G   78M  890G   1% /mnt/Dev
/dev/md126            7.3T  174G  6.7T   3% /mnt/Storage
192.168.1.21:/remote  5.5T  1.2T  4.4T  21% /mnt/NAS
tmpfs                 3.2G  228K  3.2G   1% /run/user/1000

[eantowne]

Even providing disk usage for / is less than ideal, as there is no guarantee that images/projects directories are located under /. This means the compute would need to be aware of the partition that it is using for storage.

[lurendrejer]

Will the disk-usage fix be implemented in 2.x still?

Ok, maybe we could have an aggregate for now but is it useful for disk usage?

A better solution could be to list the partitions in little boxes (same style as the memory info) at the bottom.

If i had to choose something, it would be the partition where projects reside. That is the critical point where data-loss could happen.

[eantowne]

Concur with @lurendrejer

[grossmj]

Looks like we did kind of a 360 here :smile:

Here is what we are going to do for v2, the server will report the disk usage for the partition that contains the default project directory as specified in server.conf (projects_path setting or ~/GNS3/projects if not set). Nothing in the web-ui will change.

We will redesign system status in v3 similar to CML and include some more details, probably with an advanced view.

[lurendrejer]

Thank you very very much!!