I'm definitely in favor of the pattern-oriented designs, and I do agree this is really great idea. I'm more interested in changing the RRAs per-metric than per-source, so any solution that only solved the per-source part of the problem would be less good.
The script or callback solution makes good sense to me, too -- but I wonder about speed. Some of our sources generate 25000 RRDfiles in the first minute of that source coming up. That's a fair bit of forking around if it's a script-only solution. -- ReC On Dec 28, 2009, at 3:49 PM, Jesse Becker wrote: > A few random thoughts inline below. > > Regardless of the specifics, I think this is a really great idea. > > On Mon, Dec 28, 2009 at 17:16, Daniel Pocock <dan...@pocock.com.au> > wrote: >> I'm looking at extending the gmetad.conf format, while still making >> sure >> that it can read the existing config files. >> >> There are two particular lines that interest me: >> >> RRAs "RRA:AVERAGE:0.5:1:244" "RRA:AVERAGE:0.5:24:244" >> "RRA:AVERAGE:0.5:168:244" "RRA:AVERAGE:0.5:672:244" \ >> "RRA:AVERAGE:0.5:5760:374" >> >> data_source "my cluster" [polling interval] address1:port >> addreses2:port ... >> >> My goal is to allow different sets of RRAs for different sources, >> while >> making sure the existing file format remains valid. >> >> A couple of ideas I've had: >> >> a) allow the RRAs line to be repeated - the most recent version >> will be >> applied to all subsequent data sources > > This is a good baseline rule: Last match wins. > >> b) a new option, RRAs_for_source, e.g. >> >> RRAs_for_source "my cluster" "RRA:MAX:0.5:1:244" "RRA:MAX:0.5:24:244" > > How do you handle cases where "my cluster" isn't defined? Is that a > fatal error, or a warning? Does the last (valid) match still win? > >> c) define templates: >> >> RRAs_template tmpl1 "RRA:MAX:0.5:1:244" "RRA:MAX:0.5:24:244" > > Can templates also be redefined? > > If there are templates , there has to be a precedence for what matches > are valid. I'd propose that last match wins, based on this heirarchy: > > * default definition > * data_source > * metric name > * filename (is this *always* 100% derivable from the metric name?) > * script > > My slight concern about templates is that they could make the > configuration very complicated and cause unexpected behavior. On the > other hand, having to define and redefine rules for every single > metric that needs a custom RRA, multiple times for each data_source is > just ugly. :) > > >> d) regex based filename matching: >> >> RRAs_template tmpl1 "RRA:MAX:0.5:100:240" "RRA:MAX:0.5:240:30" >> >> RRAs_template_match tmpl1 ".*/cpu_num.rrd" ".*/swap_total.rrd" > > I like this. However, it might be simpler to just limit the match to > the metric name, instead of having to deal with the preceeding > directory path, and trailing ".rrd" string. > >> e) call an external script for RRD creation, and pass it the source >> name, metric name, etc: >> >> RRD_create_script "/usr/local/bin/create-my-rrd" > > I like this, since it is inherently the most flexible, but opens us to > several security issues. I would suggest that the script return > definition of the RRA, as opposed to creating the .rrd files directly. > If this option is implemented, a basic and officially supported > script should be included. > > -- > Jesse Becker > Every cloud has a silver lining, except for the mushroom-shaped ones, > which come lined with strontium-90. > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast > and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Ganglia-general mailing list > Ganglia-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-general ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
