On Mon, Jan 04, 2010 at 06:55:36AM -0500, Jesse Becker wrote: > On Mon, Jan 4, 2010 at 03:46, Carlo Marcelo Arenas Belon > <care...@sajinet.com.pe> wrote: > >> My goal is to allow different sets of RRAs for different sources, while > >> making sure the existing file format remains valid. > > > > why do you want to have this? what is the use case for having different > > metric storage frequencies per cluster and why can't be done by having > > instead independent gmetad? > > I can think of reasons why you'd want different frequencies for the > same metric, mostly having to do with required data retention policies > and lack of resources (disk space). It could be done with different > gmetad processes, but that gets complicated for a simple cluster > (multiple gmetad polling the same gmond, the same data is displayed in > two different locations).
Of course I can think of reasons why that might be something you would want to have, and that is why I said that might be needed in the long run if those reasons are genuine, but I will be surprised if there is a reason good enough to do that from the very beginning when using multiple gmetad would solve it for now IMHO. The point is that the syntactical sugar to make that work would be far more complicated and difficult to do in a 3.1 compatible way than just adding templates and therefore I would tend to believe that it would make more sense as a 3.2 feature, while having different RRAs independently of which datasource has been in the "wishlist" since even before 3.1.0 was released and would be something you would instead want backported ASAP (probably even to 3.0 if there is demand) > > if you are talking about different metric storage frequencies per metric > > as it seems to be implied later (and which is a feature long in the > > "wishlist") > > then wouldn't be safe to assume you want that storage for that metric > > regardless > > of source?, if that is the case it will simplify the implementation and will > > only require something like "RRAs_template" as shown in "d" and not need > > "a", "b", or "c" at all (or at least not as part of the first > > implementation). > > > > currently in "data_source" the polling interval is optional and so the same > > could be done with the template to apply in the long run, but complicating > > the configuration parser, for IMHO no really good reason. > > > > using a script is definitely interesting because of the flexibility it > > allows > > for, but as mentioned before a problem because of the additional forking > > required and also problematic because it will keep part of the logic outside > > gmetad. > > Perhaps I'm misunderstanding how using a separate script would work, > but there would only be a "fork storm" during initial RRD creation, > correct? it depends on what the script does, but that is correct in the case that the script is only returning the RRAs back to gmetad as you suggested. still the disadvantage (as mentioned above) of not being able to know from just reading the gmetad.conf which RRA apply on each case still applies and would probably imply that the best way to do this will be to make gmetad modular (just like gmond) and then allow it to write its own configuration or use one by default that could be used as a starting point just like `gmond -t` allows for. > I had assumed that the current behavior of "keep existing > RRD file" would remain. Thus, the only time we would really have to > worry about "forking off hundreds/thousands of processes" would be > when a new cluster is created, or when the RRD files are all removed > for some reason. Under normal operating circumstances, the RRD files > already exist, so there's no need to run the creation script. or when gmetad is restarted and have to again figure out which RRA apply on each case for the updates and unless gmetad.conf has all that information somehow in a static way (by using for example the modular solution instead of just a script). Carlo ------------------------------------------------------------------------------ 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
