Think about a web frontend? about vtop

[keeev]

Sounds good. 👍
Any news so far?

[darrenxyli]

That's what I want! Just do it bro~

[derhuerst]

I believe that a whole web frontend is too much for a small and lightweight utility like vtop. It just feels like another utility should handle that, specifically made for web monitoring.

After googling about 3 minutes, I found Monit and Monitorix.

[MrRio]

I'm up for doing this – shouldn't be too difficult given that it's JS already. Would be cool to have some more sensors added for Apache requests/second and have the charting work in the terminal and on the web.

[derhuerst]

Please think about this again. This is a small library showing the system resources usage, made for the CLI. Currently, this library does NOT support different output channels (CLI, web, …), making it small and maintainable.

Introducing multiple output channels, embedding a web server (even if it is small) and implementing a protocol able to transfer this kind of data seems way to much for this project. According to the Unix philosophy, which has proven to be extremely useful, a module should do one thing (and do it well). In this case, it is showing the system resources in the CLI.

There are other great projects showing this kind of data using a web frontend, two of which I mentioned above. Consider porting them to node.js.

[MrRio]

Please think about this again. This is a small library showing the system resources usage, made for the CLI. Currently, this library does NOT support different output channels (CLI, web, …), making it small and maintainable.

I'm not sure if I agree with you. It would be nice to write additional sensors in the simple format I've defined and have them viewable over the web too.

Introducing multiple output channels, embedding a web server (even if it is small) and implementing a protocol able to transfer this kind of data seems way to much for this project.

It's pretty much a one liner to make a webserver in node.js, I'd probably just serve one HTML file and open a websocket.

According to the Unix philosophy, which has proven to be extremely useful, a module should do one thing (and do it well).

The Unix philosophy I agree with, it may be that the application be split into different modules, but the sensors should be compatible with both output modes. Some parts of the app are already being spun out into their own modules, like the process listing code. See #12

There are other great projects showing this kind of data using a web frontend, two of which I mentioned above. Consider porting them to node.js.

I don't really want to spend time understanding these two projects and porting them to node. Also they look like ass.

[tonylampada]

From an architecture POV, it seems reasonable to create a different project (say webvtop), that does the job by using vtop under the hood.
Maybe you'll still need to make small modifications on vtop code to support that, but that's a lot less "invasive".

[derhuerst]

@tonylampada +1

[derhuerst]

@MrRio

It would be nice to write additional sensors in the simple format I've defined [...]

Yes, absolutely!

[..] and have them viewable over the web too.

As is said: In my opinion, that's not a responsibility of this module.

It's pretty much a one liner to make a webserver in node.js, I'd probably just serve one HTML file and open a websocket.

But

• setting up a web server, serving an HTML file
• setting up a Websockets server (maybe even supporting multiple clients)
• implementing a protocol that transfers this kind of data (maybe just JSON)
• sending the data regularily
• implementing all this stuff in a readable and reasonable way (not hacked together in one line)

alltogether is not possible in one line ;D But let's focus on the do-one-thing-and-do-it-well point of this discusison.

The Unix philosophy I agree with, it may be that the application be split into different modules, but the sensors should be compatible with both output modes. Some parts of the app are already being spun out into their own modules, like the process listing code. See #12

I couldn't agree more.

I don't really want to spend time understanding these two projects and porting them to node. Also they look like ass.

That's no point to rewrite this project as a web-based.

While I think that Monit looks quite promising, I didn't want you port the whole project (my fault talking about porting), rather to reimplement it in node.js. I think such a project would be great.

[tariqbuilds]

If anyone is still looking for a web dashboard for this type of data, take a look at Linux Dash.

@MrRio If you're going to do web sockets and a simple few lines of Node, it shouldn't be too hard to accomplish the same type of web front-end for vtop. Who knows, now that you have gotten the CLI version right, maybe you can do the web front-end better than what currently exists.

Love this project!