Psdash: A linux system information web dashboard using Psutils and Flask(github.com)
github.com
Psdash: A linux system information web dashboard using Psutils and Flask
https://github.com/Jahaja/psdash
6 comments
I pretty much agree with you. The reason I built the tool was to give a system overview for the vagrant box we use at my work. Especially one that could tail and search logs (the one in supervisor is pretty useless).
And in the end; all devs aren't devops so it's easier to have it web-based.
Who knows, with time, maybe this tool can be extended to be useful for your purposes as well.
And in the end; all devs aren't devops so it's easier to have it web-based.
Who knows, with time, maybe this tool can be extended to be useful for your purposes as well.
Thanks. That makes sense as a tool for developers who don't have sophisticated unix skills. I guess quite a lot of people are targeting Linux as a production environment but come from quite different backgrounds and using different platforms for development. Once you mention vagrant it all falls into place. Nice one.
Use with caution. I was able to print my /etc/passwd file using /log/read.
FYI: /etc/passwd is world readable. You get get the same info with the command:
getent passwd
Reading /etc/shadow is a real problem, /etc/passwd is really not a huge issue.
getent passwd
Reading /etc/shadow is a real problem, /etc/passwd is really not a huge issue.
Author here (and woha, didn't note that it was posted to HN. Explains the sudden github traffic.).
Do you mean that you did that without actually passing /etc/passwd to as a --log arg to psdash? If so it's definitely a bug. The intent is to only allow viewing logs that was explicitly passed to psdash.
And as mhurron said; it shouldn't really be public anyway.
Do you mean that you did that without actually passing /etc/passwd to as a --log arg to psdash? If so it's definitely a bug. The intent is to only allow viewing logs that was explicitly passed to psdash.
And as mhurron said; it shouldn't really be public anyway.
That just means that this, like every performance dashboard, should be run internally and protected from the outside world.
I can do that with `cat`.
Seems interesting, but I need to see some charts. I think I will use psdash + loadavg (http://loadavg.com/). Until now I was using New Relic server monitoring.
How much load do tools like this add to the system. Ideally you want monitoring tools to be like using a voltmeter on an electronic circuit... display what's happening but adding very little influence of its own.
Virtually none in this case, though letting the processes page run on my system eats up 2% of the CPU (a long, updating list), versus 0% on everything else. Uses Flask.
Do these things have a harder time pulling such figures off of VPSs?
Do these things have a harder time pulling such figures off of VPSs?
Sadly, the figure was not so conservative on my Raspberry Pi (closer to 25%).
That's not very good. On all pages or just the process-list page?
I could add an option that disables the auto-updating. The only thing that's currently polled by a background thread is some network information from /proc/net/dev.
I could add an option that disables the auto-updating. The only thing that's currently polled by a background thread is some network information from /proc/net/dev.
Well I incidentally only checked while on the process page (and promptly removed it), but nice work none the less.
This is awesome
looks interesting, will give it a try.
My sysadmin brain is always looking to reduce the dependencies and the attack surface. Ideally I want less services running on less ports. Less software to install, maintain and secure. As a result I stick to ssh and shell most of the time. Generally any admin tool that has big library dependencies (eg anything python, node.js or ruby) is on my shit list. I am a bit more sympathetic to Go because of the single static exe but otherwise I prefer plain old shell.
I understand historical graphs are nice to look at and time series data is one of the areas where web tools are a win. Though I am probably more likely to look at alerts based on triggers than watch a graph in real time. I don't understand what advantage tables of process stats in html offers over the same in the cli.