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. Personally, I would like to be able to rename metrics like cpu_idle, cpu_nice, etc. to something like "cpu/idle" and "cpu/nice". As the work with dynamically loadable metrics moves forward, I can see aggregate metrics like bytes_in being replaced with per-interface versions. And rather than having to name them eth0_bytes_in, etc., I think it would be convenient to name them "eth0/bytes_in", "eth1/bytes_in", etc. > For my (Ganglia-compatible) project, I've been forced to add a work-around: > any of the characters Ganglia can't cope with are mapped to a safe character > (an underscore: "_"). This mangles the graph's title, but given the context, > people can usually figure out what the label is supposed to be. I have to do this too, mainly with directory names. Have a metric named root_usr to record the disk usage of /usr isn't too bad, but when I have a metric named root_ia64_usr_local_software_biosoft, things start to look ugly. > 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 :-) 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 ran some tests using gmetric to submit a metric named "This/is/a/test". Here is what I found: 1) gmond handled the metric fine and reported it to gmetad 2) gmetad received the metric fine, and reported it when I ran "telnet localhost 8651". 3) gmetad complained about not being able to write the metric to the rrd file. 4) gmetad couldn't properly report the metric when I used the interactive port and sent a request of the form /cluster/host/This/is/a/test. 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. While there may not be a lot of changes, they could affect compatibility (especially the changes needed to fix problem #4). So perhaps Paul's patch is the correct solution for the 3.x series, and a more thorough fix belongs in the 4.0 release. -- Rick Mohr Systems Developer Ohio Supercomputer Center
