>>> On 11/19/2009 at 9:13 AM, in message <75fb37ae0911190813q66cf1f96w1afe84f8bdbe1...@mail.gmail.com>, Sylvester Steele <sylvesterste...@gmail.com> wrote: >> I'm not sure what you are looking for. The purpose of the code that I > referred to was to show how a module would generate the metric definitions > during the initialization phase of gmond. Basically what happens is that > when gmond is started it loads each module and calls the metric_init function > for each module. At that point each module has the opportunity to tell gmond > what metrics it supports by passing back an array of metric definitions. > That is how gmond determines which module supports which metrics. The > contents of the metric definition array is completely up to the module > itself. However once the module returns the list of metric definitions, that > list can not be changed until the next time that gmond stops and restarts. > There is no way to alter the list of metrics that gmond is monitoring on the > fly during normal gmond operation. If the latter is what you are looking > for, gmond does not support on-the-fly functionality yet. >> >> >> > > > I don't want to change anything after a module starts. Changes to > which metrics are being collected can wait until a restart. But- every > time gmond restarts- this module may be collecting a different number > of standard metrics. So I don't need to change the metadata of the > metrics themselves- I just need to say at start: "OK we are collecting > these X metrics"-where X is variable and will change only at a > restart- but varies between restarts. No changes need be made after > initialization. I hope this clarifies things a bit. >
So the mod_python code that I referred to is doing that. By creating a metric_info array in your metric_init function using the apr array calls you can create a dynamic array rather than using a hard coded static array in your code. However you still have another problem. Your configuration file still needs to match up with the metrics that are being gathered. In other words, you still need to have a corresponding metic block within a collection_group in your gmond.conf configuration file whose metric name matches a metric definition that is being returned by one of the loaded modules. Right now there isn't a way to dynamically generate the gmond configuration for a metric even though the metric module has the ability to collect data for the given metic. Basically what this means is that if you expect that on a given restart of gmond that X number of new metrics are going to be collected by your metric module, you have to manually enter their corresponding configuration into gmond.conf. Adding functionality to have the metric configuration be completely driven by a metric module still needs to be done. Basically a cool feature that is looking for somebody to implement it. Brad ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
