>>> On 7/20/2007 at 4:28 AM, in message <[EMAIL PROTECTED]>, Ramon Bastiaans <[EMAIL PROTECTED]> wrote: > Hi guys, > > I'm the author of a addon to Ganglia that reports batch clusters job > statistics and information in the webfrontend. > > Right now - among other things - I make use of a daemon that submits all > the jobs information as a whole bunch of gmetrics (written in Python). > > Now I've been looking at how the Python modules are going to work and it > would be great if for the future Ganglia modules, people could just load > it as a module in stead of running it as a daemon (while still > supporting that for backwards compatibility). > > However I think I've run into a problem now. If I understand correctly, > every (python) module is initialized first with: > > metric_init(): > > And then it should return a (static) list of metrics that module is > going to report. Am I correct to understand that after this init, the > amount and names of the gmetrics reported by the module cannot change > anymore from the list returned by metric_init? > > For my particular purpose, the amount of gmetrics and their names vary > each time it is polled. This is because I submit the job information as > metrics named after their jobid in the batch system, for example: > > <METRIC NAME="MONARCH-JOB-56372-0" VAL="status=R > start_timestamp=1184925586 name=STDIN poll_interval=30 > domain=gina.sara.nl queue=short reported=1184926420 > requested_time=04:00:00 queued_timestamp=1184925585 owner=lhcb008 > nodes=wn02" TYPE="string" UNITS="" TN="17" TMAX="60" DMAX="60" > SLOPE="both" SOURCE="gmetric"/> > > Since the jobs ids/amounts may/will vary at each polling interval, the > metric names, amount and list changes each time it is executed. > > Now it would be great if I could 'simply' "modulize" my code by adding a > couple of Ganglia/gmond specific functions that spit out the Gmetrics in > a form that gmond wants to, but it seems with the current (metric) > initilization setup as described in the README and example.py my code > will never work and would require significant rewrite of my web addon. > > Is there any way the (python) module support could be changed to support > a dynamic/changing list/names of Gmetrics? > > Or is that technically difficult to achieve in gmond, with regard to > memory allocation etc? > > I can imagine that authors of other scripts/modules might encounter the > same issue later on. For example for other changing/dynamic system > resources that they would like reported from a module. > > *phew* someone read all the way up till here. ;) > > Or am I completely missing the boat here? > > Cheers, > - Ramon. >
The bad news is that your assumptions about the python interface is correct. When gmond starts up, it calls the metric_init() function to obtain a list of metrics that the module will report on. How that list is generated is up to you. In the example module it is hard coded, but if you look at the multidisk module you will see that during the metric_init() function, the module detects the number of physical disks that are on the machine and dynamically creates the metric list. Of course once the list is generated and returned, it can not change. The main reason why the metrics list can not change is due to how gmond is architected. Gmond maintains an internal list of all of the metrics that it knows about associated with their definitions (basically the same information that you give gmetric on the command line) and the callback function that should be called whenever the metric value needs to be gathered. Once this internal list has been created, there isn't any way to alter it. However, in your case there might be a way around it. You could write a module that implements a single metric and provides a callback handler for that metric. Your callback handler would be required to return some value which could be just a status value indicating that your module is still alive. But whenever your module is called, it could take advantage of the functions in libganglia and generate all of the gmetric type metrics using the libganglia apis in the same manner as gmetric. The tricky part is that the libganglia APIs are all written in C and if you called them from python, you would have to create and apr_pool (there is a libganglia API for this) that can be passed in to the libganglia APIs for memory allocation. Brad ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
