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). > 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? 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. -- 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