Re: [Ganglia-developers] mod_gstatus disabled?

[Brad N. <BNI...@no...>]

>>> On 7/28/2009 at 9:32 AM, in message <4A6...@po...>, Daniel
Pocock <da...@po...> wrote:
> Brad Nicholes wrote:
>>>>> On 7/28/2009 at 7:27 AM, in message <4A6...@po...>, Daniel
>>>>>         
>> Pocock <da...@po...> wrote:
>>
>>   
>>> I noticed a few things about mod_gstatus:
>>>
>>> - the spec file doesn't include it at all, and deliberately removes the 
>>> config file for it
>>>
>>> - gmond/modules/Makefile.am excludes it from static builds
>>>
>>> Given that Ganglia is modular, is there a good reason for not having 
>>> this module in the RPM along with all the other modules?
>>>
>>> I successfully compiled it on Cygwin (static build), so is there also a 
>>> reason for not having it on static builds, or in other words, does 
>>> anyone object if I tweak Makefile.am so it will be in the static build 
>>> from now on?
>>>
>>> Also, I'm adding some extra metrics to mod_gstatus - for instance, a 
>>> string metric with the Ganglia version - does this seem like the best 
>>> place to add this?
>>>
>>>
>>>     
>>
>> The only reason for removing it from the RPM and static builds is basically 
> due to its likely usefulness to the general user.  When I wrote mod_gstatus 
> it was mainly for debugging purposes.  I needed something that would monitor 
> the XDR packets that were being sent between the gmond nodes and using 
> ganglia to monitor itself seemed like the most obvious idea.  If the 
> community thinks that mod_gstatus would be generally useful, I don't have a 
> problem with including it as a standard module.
>>   
> My only concern about enabling it by default is the config file - all 
> the metrics should probably be commented out, and people can uncomment 
> them if needed.
> 
> It is probably quite useful for a UDP collector that is under heavy 
> load, and I also think it is a good place to put things like a string 
> metric reporting the package version.  That's probably something that 
> could be enabled by default on any node.
> 
> 

I'm OK with that as long as the community thinks it is useful.  I just didn't want to load up extra modules and use up more memory if the metrics don't mean anything to the end user.