>>> On 7/1/2008 at 8:48 AM, in message <[EMAIL PROTECTED] , <[EMAIL PROTECTED]> wrote:
>> > - How should such a module handle disks that are not always >> present, >> > e.g. iSCSI SAN volumes attached after the process has >> started? Is it >> > appropriate to re-initialise the list of metrics while gmond is >> > running, or is it necessary to restart the entire gmond >> process each >> > time disks (or NICs) are attached/detached? >> > >> >> In the current implementation, gmond will have to be >> restarted in order to recognize new disks. I have looked >> into a way for the metrics list to be reinitialized on the >> fly, but haven't been able to come up with a good >> implementation. Part of the problem is that any new metric >> also requires a configuration file change. There would have >> to be some way for either a module or a user to poke gmond >> and tell it to re-read the configuration file and then >> reconstruct the metrics list without dropping any of the in >> memory data. I am guessing that a robust implementation will >> probably also include some way of generalizing the >> Collection_Group configuration section so that each metric >> does not have to be listed individually. The set of enabled >> metrics would somehow have to be generated on the fly. >> > > > How about metric instances, e.g. if the metric is the number of IO > reads, there could be an instance for each volume. All of these > instances might share the same name and/or index, but have some kind of > sub-index for each instance (e.g. hda, hdb) > > Such a scheme would need an additional discriminator field in the XML, > and gmetad might have to split the rrds into sub-directories. > Something like that could work. The metric spoofing functionality actually does something similar already. Brad ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
