On Mar 7, 2010, at 10:57 AM, Daniel Pocock wrote:
> Peter Phaal wrote:
>> Hi all,
>>
>> We are considering using libmetrics as a stand-alone library. In its current
>> form, with the separate configure script, it looks like it would ideally
>> suite our purposes. I noticed a recent discussion about dropping the
>> separate configure script[1] and wanted to express our interest in keeping
>> it. The discussion also mentioned licensing. It looks like all the elements
>> of the library are
> As I see it, the current libmetrics/configure is broken, and the way it
> is invoked is also broken:
>
> - when it is invoked from the top-level configure, none of the command
> line options are passed to it, this is particularly bad for
> cross-compiling, multilib, etc
>
> - many of the configure tests are run twice on each build, which is
> inefficient and painful for developers, configure takes a long time on
> Cygwin in particular
>
> - code has to be duplicated across both configure scripts
>
> As I see it, there are three ways forward:
>
> a) separate libmetrics into an independent project, independent package,
> etc with a well defined API - this would be ideal if there is genuine
> demand from projects like yours, as you wouldn't have to download all of
> Ganglia just to play with libmetrics
>
> b) scrap the separate configure script, merge it into the top-level
> configure. If someone does only want to build libmetrics, they can
> still do so by running a command like this:
>
> ./configure --enable-static && make -C libmetrics
>
> c) hack the scripts even more to deal with the problems I have described
> (e.g. passing command line options to the nested configure)
>
> I have endorsed solution (b) simply because it is easier and I was
> unaware of demand for option (a). If there is demand for option (a),
> then I have no objection to that solution. The only solution I object
> to is (c), the status quo.
Option a, separate libmetrics into an independent package would best serve our
purposes. More generally, a stand-alone library would encourage developers to
add support in scripting languages and make it much easier to write portable
performance monitoring tools.
I am not aware of an alternative to libmetrics providing similar capabilities.
Most performance monitoring tools seem to be proprietary, or tied to specific
operating systems. An independent package would encourage a wider set of
developer contributions since it would engage a broader developer community.
The library would encourage consistency between tools reporting on system
performance, making it easier to compare results.
It looks like libmetrics is already fairly independent, requiring only a few
simple utility functions from lib (e.g. lib/file.c) that could be replicated in
order to create a stand-alone library. If changes are needed to the build
process for libmetrics anyway (option b), then it doesn't look like it would be
much extra work to make the library independent (option a).
>
>> Is there a document that describes the standard set of metrics in the
>> library? I am looking for a document with formal/semi-formal definitions for
>> each metric that I could cite when referencing metric names in an sFlow XDR
>> structure[4].
>>
>
> I am not aware of such a document, anyone else can comment? Maybe it
> could be done in the wiki
The best I could find was the following table from the README. The table
doesn't list all the platforms correctly (I did a couple of spot checks and
darwin includes cpu_num, cpu_speed .. but is not listed in the table) and
doesn't provide much detail.
This table describes all the metrics that ganglia collects and shows
what platforms the metric are supported on. (The following table is
only partially complete).
Metric Name Description Platforms
-----------------------------------------------------------------------
boottime System boot timestamp l,f
bread_sec
bwrite_sec
bytes_in Number of bytes in per second l,f
bytes_out Number of bytes out per second l,f
cpu_aidle Percent of time since boot idle CPU l
cpu_arm
cpu_avm
cpu_idle Percent CPU idle l,f
cpu_intr
cpu_nice Percent CPU nice l,f
cpu_num Number of CPUs l,f
cpu_rm
cpu_speed Speed in MHz of CPU l,f
cpu_ssys
cpu_system Percent CPU system l,f
cpu_user Percent CPU user l,f
cpu_vm
cpu_wait
cpu_wio
disk_free Total free disk space l,f
disk_total Total available disk space l,f
load_fifteen Fifteen minute load average l,f
load_five Five minute load average l,f
load_one One minute load average l,f
location GPS coordinates for host e
lread_sec
lwrite_sec
machine_type
mem_buffers Amount of buffered memory l,f
mem_cached Amount of cached memory l,f
mem_free Amount of available memory l,f
mem_shared Amount of shared memory l,f
mem_total Amount of available memory l,f
mtu Network maximum transmission unit l,f
os_name Operating system name l,f
os_release Operating system release (version) l,f
part_max_used Maximum percent used for all partitions l,f
phread_sec
phwrite_sec
pkts_in Packets in per second l,f
pkts_out Packets out per second l,f
proc_run Total number of running processes l,f
proc_total Total number of processes l,f
rcache
swap_free Amount of available swap memory l,f
swap_total Total amount of swap memory l,f
sys_clock Current time on host l,f
wcache
Platform key:
l = Linux, f = FreeBSD, a = AIX, c = Cygwin
m = MacOS, i = IRIX, h = HPUX, t = Tru64
e = Every Platform
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
