Re: [Ganglia-developers] Getting code into Ganglia

[Richard M. <rf...@os...>]

Paul,

> > I can think of a third: Logically organizing related metrics.
[snip]
> (As an aside, I'd point out that your use-case above is assigning additional 
> semantics to the "/" character: that of a separator when "flattening" a 
> hierarchy of metrics from a host.  That's perfectly legitimate, but the other 
> two cases merely have the "/" as part of the name and no need for any 
> additional semantics.)

My original intent was to assign the same semantics for all cases.
Since gmond doesn't write anything to disk, it doesn't know (and doesn't
care) about the role that the "/" character plays.  Only gmetad cares,
and it could be implemented to always assume that "/" always signifies
hierarchical storage.

However, after reading some of your comments, I had to rethink my
original idea.  A metric named "/usr/local" maps very easily onto a
hierarchical storage scheme, and at the same time, people can readily
identify what this metric represents.  But then I realized that if the
metric was named "filesystem(ext3):/usr/local", I wouldn't necessarily
want gmetad to create a "filesystem(ext3):" directory when it store the
metric.

So now I see why you considered "/" to carry two different semantics.

> In summary: I'm generally in favour of (someone other than me :-) adding 
> support for a hierarchy and using the directory structure to handle this 
> hierarchy makes sense.  But this doesn't fix the problem mentioned in bug 
> #120.  Certain characters are illegal under certain filesystems: "/" in 
> Linux, "\" (and many others) under Windows.  If Ganglia is going to support 
> metrics with these potentially f/s-illegal characters it needs some means to 
> hiding them from the underlying filesystem.

Two solutions come to mind at the moment:

1) Ganglia chooses a set of characters that are considered valid in
metric names.  That set would be relatively simple and contain only
those characters which are f/s-legal across all filesystems.  (Maybe [A-
z][a-z][0-9][_.] or something like that.)  In addition, the "/"
character would be allowed and its purpose would always be to signify
hierarchical metric storage.  Gmetad would always translate this to the
proper directory separator for whatever filesystem it is running on.

2) Any "special" characters in metric names are always escaped.  Then to
signify a metric hierarchy, there would need to be a way to explicitly
define a "parent metric".

Solution #1 would be relatively clean and easily implemented, but it
might break compatibility w/ the current implementation,  It may also be
a bit too limiting in regards to metric naming.

Solution #2 might be a better design choice, but it is probably much
harder to implement. There is also the question of how to handle cases
where you want to group metrics under a "parent", but the parent name is
just a useful group name and isn't actually a reported metric.

I suppose this is an issue for minds greater than mine to decide.  And
until it gets decided, I suppose your patch is probably the correct way
to proceed.  But I did have one idea I wanted to toss your way in
regards to the escape sequences your patches use:

Would it make more sense to use an encoding scheme like the one that
already exists for URLs? (/ = %2F, <space> = %20, etc.)  This might be
handy for the PHP web frontend (which has to encode these characters
anyway), and it is widely known (so nobody would have to guess which
character ^s represented).

-- 
Rick Mohr
Systems Developer
Ohio Supercomputer Center