Thanks, Matt!

I believe such a feature could bring Ganglia a big step forward. It
would now be possible to use Ganglia for performance monitoring of
devices using SNMP, IPMI and the likes.

Also, I bet your implementation would be much "cleaner" than mine and
would involve much less hair pulling...


I want to use this opportunity to raise some questions regarding
Ganglia's future roadmap, as I couldn't find one on the web:

   1. Is there planned support for 64 bit integer metrics? Large
      clusters quite easily exceed the 4TB aggregated memory limit
      enforced by using an unsigned 32 bit integer. Not to mention
      aggregated bandwidth on Gbit Ethernet.
   2. Is there an planned implementation for graph templates (style
      Cacti maybe)? I have something half-done but it got pushed way
      down on my list of todo's... if anyone wants to pick it up, I'll
      be happy to provide the (ugly) code and help as much as I can.
   3. Is there a roadmap, list of planned features or some kinda
      wishlist anywhere? Ganglia is quite good at what it does... my
      question is, how can we help in making it better?

Thanks,

Alex



matt massie wrote:

> i think i misunderstood your question before.. sorry...
>
> in terms of supporting explicit setting of hostname/ip in the
> messages, it would require some work.  given that there is a good
> demand for the feature i think i will make it my top priority when i
> have some time (hopefully pretty soon).  something like
>
> struct Ganglia_gmetric_message_from {
>     char *ip;
>     char *hostname;
>    Ganglia_gmetric_message message;
> };
>
> would easy to add to the ./lib/protocol.x description.  however, i'd
> need to write the gmond code to process the new message format (not
> too bad).
>
> -matt
>
>
> On Apr 11, 2006, at 1:07 PM, Alex Balk wrote:
>
>> Hola,
>>
>>
>> Thanks for the correction. I was thinking along the lines of gmetric
>> flags rather than functions.
>>
>>
>> Still, I'm trying to add a cmdline/config option to make gmond appear to
>> be reporting for a different host. After some code digging it seems to
>> me that the receiving gmond determines the "hostname" value by seeing
>> where the connection comes from rather than by looking in the message
>> payload for some HOST tag. This changes things from "trivial" to
>> "where's my coffee"
>>
>>
>> To get the functionality I want I was thinking along creating a new
>> metric called "hostname" as an override (when it exists). This raises a
>> few questions:
>>
>>    1. Does that make sense at all?
>>    2. Would it break backwards compatibility?
>>    3. The hosts hash is indexed by IP - if a supplied hostname doesn't
>>       resolve would it be legitimate to just throw away the data and
>>       issue a warning?
>>    4. What's the purpose of this:  apr_gethostname( myname,
>>       APRMAXHOSTLEN+1, global_context);
>>    5. I'm sure there's a whole lot more I haven't tripped over yet...
>>
>>
>> Thanks,
>> Alex
>>
>>
>> matt massie wrote:
>>
>>> it is possible and not too painful.
>>>
>>> path #1: use XDR directly in your application
>>>
>>> you'll need ./lib/protocol.h and ./lib/protocol_xdr.c from the ganglia
>>> distribution.
>>>
>>> in your application, you need to fill in a Ganglia_gmetric_message
>>> structure and then send it using XDR to your multicast/unicast
>>> channel.. for example...
>>>
>>> ======= start code ============
>>> Ganglia_gmetric_message message;
>>> /** fill in the strucuture ... */
>>>
>>> XDR xdrs;
>>> char msgbuf[BUFLEN];
>>> xdrmem_create(&xdrs, msgbuf, BUFLEN, XDR_ENCODE);
>>> xdr_Ganglia_gmetric_message(&xdrs, &message);
>>> u_int len = xdr_getpos(&xdrs);
>>> ======= end code =============
>>>
>>> that's it!  now your message buffer (msgbuf) has len bytes of data to
>>> send package in ganglia XDR format.... ready to send to your favorite
>>> gmond.
>>>
>>> path #2: use the helper functions in libganglia
>>>
>>> if you open up ./gmetric/gmetric.c you'll find that it just uses the
>>> libganglia helper functions to send message.  these helper function
>>> will parse the local gmond configuration file, setup the channels,
>>> populate the Ganglia_gmetric_message structure and send it for you.
>>>
>>> let me know if this helps.
>>> -matt
>>>
>>>
>>>
>>>
>>>
>>> On Apr 11, 2006, at 9:07 AM, Alex Balk wrote:
>>>
>>>> Hi Egan,
>>>>
>>>>
>>>> That's not possible at this point.
>>>>
>>>> It's an interesting idea, though. I'd go with pushing the data into
>>>> gmond if you're doing unicast, though. That way when gmetad polls it,
>>>> the data would get written out to the rrds without having to modify
>>>> any
>>>> gmetad code.
>>>>
>>>> If you're doing multicast, it would probably be different (I'm not
>>>> sure
>>>> if it'd be practical or at all possible, as all gmonds hold all the
>>>> data)... worth checking out though.
>>>>
>>>>
>>>> Hopefully I'll get to check this out this weekend.
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Alex
>>>>
>>>>
>>>> Egan Ford wrote:
>>>>
>>>>> I have a large cluster and I would like to collect HW data, but do
>>>>> not want
>>>>> to call gmetric on each node, e.g. today each node has to run:
>>>>>
>>>>> gmetric --name temp --value 30 --type int16 --units Celsius
>>>>>
>>>>> Since I can get the data without impacting the OS, how can I get the
>>>>> data
>>>>> into gmetad?  Something like:
>>>>>
>>>>> gmetric --name temp --value 30 --type int16 --units Celsius --host
>>>>> node1
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>>> language
>>>>> that extends applications into web and mobile media. Attend the live
>>>>> webcast
>>>>> and join the prime developer group breaking into this new coding
>>>>> territory!
>>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Ganglia-general mailing list
>>>>> [EMAIL PROTECTED]
>>>>> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>>>> language
>>>> that extends applications into web and mobile media. Attend the live
>>>> webcast
>>>> and join the prime developer group breaking into this new coding
>>>> territory!
>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>>>
>>>> _______________________________________________
>>>> Ganglia-developers mailing list
>>>> Ganglia-developers@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/ganglia-developers
>>>
>>> [EMAIL PROTECTED]
>>>   http://massie.us
>>>
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>> language
>> that extends applications into web and mobile media. Attend the live
>> webcast
>> and join the prime developer group breaking into this new coding
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Ganglia-developers mailing list
>> Ganglia-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ganglia-developers
>
> -- 
> [EMAIL PROTECTED]
>   http://massie.us
>
>
>

Reply via email to