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
