Quoting Paul Millar <[EMAIL PROTECTED]>:
> Hi Christian,
>
> On Tuesday 09 October 2007 21:19:24 Christian Gouret wrote:
>> Propose solution : Ganglia already manage a "SOURCE" field in the xml, as
>> far as I understand hard code by Ganglia, use to describe if the metric is
>> a gmond or a gmetric one.
>> If we would have the possibility to set this "SOURCE" field on the gmetric
>> API to a special string, it would become possible to order each gmetric
>> metric of a cluster in a "SOURCE", and after have a way to filter in the
>> front end using the "SOURCE" field.
>> For example SOURCE will be set with value as : disk, snmp, fan, network,
>> http, messaging, database,...
>> This "SOURCE" field would also be use to configure the metric location (
>> local disk or tmpfs filesystem ).
>
> A friendly amendment to your solution: we keep SOURCE as-is (i.e. gmetric,
> gmond), but add an extra field GROUP for group membership. I'd say it's
> better not to overload the meaning of SOURCE (actually, I'd prefer to see
> SOURCE dropped: a metric is a metric, whether it comes from gmond or
> gmetric).
>
> One further possibility would be to make GROUP a comma-separated list of
> group-names for the groups the metric is a member of. So, a disk-temperature
> metric might have "disk,hardware" to indicate its a member of both
> group "disk" and group "hardward", a fan metric might have
> GROUP="fan,hardware". The web front-end user could select "hardware" and see
> both metrics, or "fan" and see just the fan metric(s).
>
> However, this is kinda awkward, as we are implicitly providing a hierarchy of
> metrics though simple group-membership, which is often messy (how do you
> alter the hierarchy without changing all metrics?).
>
> Perhaps doing this explicitly would be better. For example, if the following
> assertions where held centrally (e.g. within PHP front-end)
> {temperature-metric is-a hardware-metric},
> {disk-metric is-a hardware-metric},
> {cpu-metric is-a hardware-metric},
> {fan-metric is-a hardware-metric},
> {hardware-metric is-a host-specific-metric}
>
> Measurements of disk-temperature would be advertised as {temperature-metric,
> disk-metric}, CPU temperature as {temperature-metric, cpu-metric}, fan speeds
> as {fan-metric} and load-avr as {host-specific-metric}.
>
> The web front-end user can select:
> hardware-metric and see cpu-, hd-temperature and fan speeds but not
> load-avr,
> temperature-metric and see just cpu- and hd- temperatures,
> host-specific-metric and see all four metrics above.
>
> This is really just using the RDF/RDFS terminology, so there's already exists
> software to support this sort of thing.
>
> Cheers,
>
> Paul.
>
I think allowing metrics to members of multiple groups is a useful idea.
Could the <METRIC> item contain child items, like :
<METRIC name="disk-temperature">
<GROUP>hardware</GROUP>
<GROUP>disk</GROUP>
</METRIC>
This would allow the web frontend to do XPath queries on the XML and
find any metrics in a requested group, without having to store the
list of groups in a config file anywhere.
Storing this data in the web frontend's config file would definitely
be better performance-wise, and would keep the size of the XML
smaller, so maybe that's a better route to go. But the idea of the
data being self-describing is also appealing. Just an idea.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
