Hi Rick, On Tuesday 06 March 2007 15:40, Richard Mohr wrote: > On Mon, 2007-03-05 at 16:14 +0000, Paul Millar wrote: > > I think that, like it or loath it, people may have legitimate reasons to > > use the "/" character. The are two specific use-cases I'm thinking of: > > plotting disk-partition- and VO- statistics (but other probably exist). > > I can think of a third: Logically organizing related metrics.
I agree! I think Ganglia could display its many graphs in a much cleaner fashion with the adoption of a hierarchy of metrics. (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.) [...] > > To my mind, having to mangle metrics' titles is more ugly than gmetad > > marking up any unrepresentable characters within a filename. > > Here is where I only partly agree with you Paul :-) Aye... :-) > I agree that > mangling the filename is better than mangling the metric name, but I am > not convinced that either is necessary. I think the better solution is > to fix gmetad so that it can store the metrics in a hierarchical fashion > as well. I'm in favour of hierarchical metrics and would be in favour of this, but I think there are two separate issues here: supporting hierarchies and supporting metrics with filesystem illegal (f/s-illegal) characters. > I ran some tests using gmetric to submit a metric named > "This/is/a/test". Here is what I found [snip: description of gmetad having a problem] This is what I found, too. > Problem #3 is the result of "rrdtool create <file>" not being able to > create directories if <file> contains more than just a straight file > name. This could be fixed by having the RRD_create() function in > rrd_helpers.c handle the directory creation. > > Problem #4 could be trickier to handle. I am not familiar with the > "filtering" aspect of gmetad's interactive port. Since it uses a syntax > like /cluster/host/metric, it may be difficult to determine where the > metric begins if it contains "/" characters. > > As far as the web frontend goes, it looks like most of the PHP uses > rawurlencode/rawurldecode to handle passing URL query parameters. So it > would probably require very little change to support metrics with "/" in > them. > > And of course, there is also the issue of Windows support. In that > case, it would just be a matter of translating "/" to "\" in the file > paths. ... and here's the rub. Suppose I want to store a metric "A/s" and "A\s". Both "A/s" and "A\s" are distinct metrics and neither is part of a hierarchy: they are both simple names (albeit awkward ones). If a hierarchy was introduced, then one question is whether it support an escaping mechanism, to allow a "/" in a name? If there is no escaping mechanism, then "A/s" would be forced into a hierarchy, which is wrong. If the "/" is escaped (as "A\/s", say), then we're back to the original problem of how to store a metric with a literal "/", which is an illegal character within a (Linux VFS) filename. With Windows it gets really confusing. If one maps "/" to "\", then there will be no way to distinguish between "A/s" and "A\s", unless the names are escaped. If they are escaped, then the same problem exists: how to store a literal "\" within a filename. Windows is fun because one can concoct all manour of illegal metric names: a metric with any of the following characters should fail: " / ? < " > \ : * |", although I've not tried them. 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. Cheers, Paul.
pgpOL0TbcpqQd.pgp
Description: PGP signature
