Results 1 to 5 of 5
Thread: Performance Metric Collect
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Nov 2011
Performance Metric Collect
I want to collect performance metrics on my SUSE 11.4 machine, it turns out that I have to install sysstat to collect the network I/O stats.
Is there any alternatives without installing any software?
Yes, but it is tedious and would basically reinvent the wheel.
It is also not trivial to do correct.
- /proc/stat contains system statistics.
- /proc/uptime contains system uptime.
- /proc/partitions contains disk statistics (for pre 2.5 kernels that have been patched).
- /proc/diskstats contains disks statistics (for post 2.5 kernels).
- /sys contains statistics for block devices (post 2.5 kernels).
- /proc/self/mountstats contains statistics for network filesystems.
In theory, one could read the io metrics for all drives from these sources and reimplement the iostat calculations in whatever language is already installed on your suse 11.4 machine.
But frankly, I dont think this is a good idea.
What is blocking you from installing sysstat?You must always face the curtain with a bow.
- Join Date
- Nov 2011
Thanks, Irithori for your quick response. Our Linux server is very critical to our business, we have certain IT policies against installing softwares on the server. Is there anything else I can use, like a script or something?
Btw, why they took sysstat away? I remember it's a build-in utility in earlier version...
Policies are good.
I like them.
I enforce them at my workplace.
But they must have purpose and reason.
What I understand from your post is, that you are not allowed to install anything ontop of a base install of suse.
Is that correct?
Then, how are updates handled at your place? Specifically, what is the source of these updates?
It is perfectly reasonable to have a policy, that forbids random software installs from unknown sources (some new alpha stage software from github, forums, etc)
It is also best practice to keep the number of software packages on a server low.
But the case here is about sysstat.
This is stable and known software.
It is part of your suse install media.
There is absolutely no reason to trust e.g. the package "coreutils" from the suse DVD,
but not "sysstat" from the same source.
Also: If you decide to clone the functionality of sysstat
- you need to invest time to develop that
- you need time to maintain this new software
- you would need to copy that clone to the server as well. This is also essentially a software install.
- Not trying to be mean, but it is unlikely that the first version of that clone would be as good as sysstat.
- Other tools, that rely on sysstat (monitoring solutions like munin, xymon, etc) can probably not be used with the clone.
Especially *because* that server is so business criticall, it cannot be without monitoring. (or redundancy or backup or documentation or access restrictions, while we are at it )
Maybe redefine that policy to contain a whitelist of allowed software.
Or tweak the installprocess to include sysstat. I believe suse uses AutoInstall/AutoYast?
Just my 2cents.You must always face the curtain with a bow.
- Join Date
- Nov 2007
how about collectl? if does everything sysstat does and then some. it's very light-weight and runs at a default monitoring interval of 10 seconds unlike sar which runs at 10 minutes - I still have no idea why! taking samples that infrequently doesn't really produce any meaningful data unless of course you're looking for events of a 10-20 minute duration.
but best of all, collectl is part of the suse build service, whatever that is, but is it something considered part of the distro.