Follow-up on "Linux server monitoring tools" | Hacker News Reader

Follow-up on "Linux server monitoring tools"

aarvik.dk

116 pointsadionditsak20 comments

From the description of linux-dash:

> It is easily extensible from its architecture which just calls the php exec() function and sends it to an ajax request.

I presume the network police have already revoked somebody's license to run a server, yeah?

Well, i did not write it! I just tested it :-) But that is how it is build. It came on HN same time as my post. Here it is: https://news.ycombinator.com/item?id=7125153

I also believe that exec() is not dangerous if you use it right, and if your www-data/apache-user do not got any sudo rights to risk someone to take advantage of your machine. This have been proved from various sources, if i know right. I understand it can be a security hole if you let the user write anything, but this is eg. not the case with Linux-dash.

local shell is as good as root as far as I'm concerned.

especially if that machine is single purpose, which most of mine are.

SELinux if left enabled (as it should be...) will help mitigate the risks. But root access often isn't necessary to totally screw you. For example, adding a machine to a botnet does not require root, nor does accessing the data for your application (such as databases and local files owned/manipulated by your apache user).

> I also believe that exec() is not dangerous if you use it right

Just about anything can be "safe" if "used right" - that's a caveat big enough to land a 747 in, one only need define all unsafe uses as incorrect for it to become a truism that tells us nothing. And that's a pretty defensible definition for anything web facing!

Statistics will eventually catch up to us, and we will eventually find new and novel ways to use things wrong despite all attempts not to. Ergo: exec is dangerous. With care, you may safely navigate the danger.

For my own curiosity, I looked at some of the source. I'd fear parsing all those $ and {}s in strings to verify they're all awk variables and not PHP variables would quickly desensitize me to actual errors when reviewing or auditing such code. I'm not a PHP dev: Hopefully you have lint tools or somesuch less ignorable than syntax highlighting to catch the stray typo which eludes human review? As others have mentioned, lack of sudo is far from sufficient protection.

Widening the net a bit but since you added network-connected monitoring, check out sensu. It's backward-compatible with nagios plugins and handles cloud systems very well (no need to restart the server every time a host is being added/removed). It's also capable of extracting system metrics and forward them to graphite/... . Really great tool.

And just for metrics, collectd is great too.

Nice zimbatm, i will definitely take a look at those :-) Sounds great with Nagios + cloud systems integration.

While I agree that Sensu could be cool, their utterly uninformative website makes me want to break the fingers of whomever was in charge of that site design.

Worst website design EVER for any monitoring system in existence.

I use https://github.com/bpowers/psm every day at this point. Simple, fast and filterable memory reporting. disclaimer: I also wrote it.

I am using PSM quite frequently too. Thanks for the library.

Is there a nice open-source solution for monitoring multiple servers? I don't want a separate http daemon on every one of them, just so I can log in there occasionally. It would be most helpful to have a separate server, which will collect data and logs from all of my other machines, through a lightweight network interface. SMS/E-mail notifications and a tray app for Mac won't hurt either.

There is always AWS, but for my side projects, I prefer cheaper VPS.

Check out Zabbix or Icinga

More than you can shake a stick at.

For graphing: Munin, Cacti, Graphite, and ganglia are the normal options. Graphite is the most powerful of these. It doesn't do any actual monitoring though. Munin is the simplest to implement.

For general monitoring and alerting: Nagios (and its clones: Shinken, Icinga, and Naemon) is the standard. There's also newer projects like reconnoiter (which suffers from awful documentation, but looks like it could be really nice), and Sensu (who's got quite a bit more documentation than reconnoiter, and looks like it could be quite good). A reasonable number of people use Zabbix as well - the main benefit of this seems to be a nice GUI for management (but I've never used it, so take my comment with a pinch of salt). Graphs (and almost anything you want) can generally be added to nagios and clones if you're willing to do a little work. Reconnoiter seems to have graphs out of the box. I don't know about zabbix or sensu.

There's more tools that you can use for log monitoring - I think that's a whole separate area, but if you're interested, ping me and I can point you in the direction of the right tools :-)

I'm writing a ruby script to gather statistics from a Raspberry Pi. All the projects I've seen so far rely on Perl/Python/PHP scripts which are executing shell commands to extract informations every X minutes.

I wonder, isn't there some sort of API to access in Unix-based systems data like CPU usage, memory usage, etc in a more natural way?

Why, yes, there is.

Go run strace on ps or top and see what they call.

I'll save you some time: it turns out to be stat() and open() on things in /proc.

i know this is much easier to use, and arguably looks much better. but maybe for more serious use maybe consider using munin [1] or cacti? [2]

[1] http://munin-monitoring.org/

[2] http://cacti.net/screenshots.php?page=1

We have plans to add (free) server monitoring to App Enlight. I would be more than delighted for you guys to comment here:

https://github.com/AppEnlight/main/issues/29

and tell us what you would like to see.

Can Linux-Dash provide with a history of CPU load , memory etc or does it only provide the current stats ?

Only current data. It is a very simple tool. If you clone it to your Web server it should work already, if you want to test it.

Reply on news.ycombinator.com