I checked in the new sFlow proxy.
There are just config settings, both optional, so you typically don't need an
sflow { } section at all, just the udp_recv_channel for 6343. However if you
wanted to run sFlow in on an non-standard port such as 7777 and you also wanted
to see any VMs that may be reported-on by their hypervisors, then you would
add this to gmond.conf:
udp_recv_channel {
port = 7777 /* for sFlow */
}
sflow {
udp_port = 7777 /* non-standard port */
accept_vm_metrics = yes
}
All physical (non-VM) metrics will be accepted by default, so the first thing
you will see if you are running host-sflow agents is the inclusion of metrics
such as "swap_in" and "swap_out".
I added documentation to the gmond/conf.pod file, but I don't know if/how this
gets into the man page(?)
Please let me know if there are any problems.
Neil
On Feb 24, 2011, at 4:17 PM, Neil McKee wrote:
>
> On Feb 24, 2011, at 3:07 PM, Bernard Li wrote:
>
>> Hi Neil:
>>
>> I finally had a chance to test out the patch. Didn't run into any
>> major issue on my end, so +1 from me.
>>
>> On Thu, Feb 17, 2011 at 2:22 PM, Neil McKee <neil.mc...@inmon.com> wrote:
>>
>>> There are three metrics to draw particular attention to:
>>>
>>> 1. System UUID
>>
>> I noticed that on my Windows host, UUID is
>> 00000000-0000-0000-0000-000000000000. I guess UUID generation on
>> Windows is not supported yet? I tested with hsflowd 1.12 on Windows
>> XP.
>>
>
> The Windows UUID appears for me, but that's from a Windows7 OS. Maybe we
> would need to look in a different place on XP. (The Linux port falls back on
> the UUID of the first local disk if it can't get a UUID for the whole system,
> so maybe something similar to that would be acceptable as a work around.)
> Please raise this question on host-sflow-discuss.
>
>
>>> The "Datasource ID" and "Parent Datasource ID" can be treated as opaque
>>> strings that the UI could use to capture and represent the containment
>>> hierarchy.
>>
>> Perhaps you could explain a bit about the format of "Datasource ID"?
>
> The specs on sflow.org cover this, but basically it consists of
> {IPAddress,dsClass,dsIndex} where the IPAddress can be a v4 or v6 address,
> and the dsClass tells you if the dsIndex is referring to an interface, a
> physical entity or a logical entity (such as a VM or application).
> Conceptually I think of each datasource as being one "observation point" in
> the system. From ganglia's perspective it's probably best to treat it as an
> opaque string, and just use it to know, for example, that a particular VM
> is running on a particular hypervisor.
>
>>
>> I've granted you SVN access, so please feel free to check the code
>> into trunk. But perhaps Brad might want to review the code quickly
>> before you do so :-)
>
> OK. I'll wait for Brad to comment.
>
>>
>> Can you also modify the manpage for gmond.conf plus add it to the
>> default configuration? I'm okay with "accept_all_physical = yes" as
>> the default.
>>
>
> OK.
>
>> BTW, are you interested in implementing UUID for gmond? We've been
>> talking about using UUID instead of hostname/IP as host identifiers
>> because those things could change, so I think this would be a great
>> feature to be added to our code base.
>>
>
> I really don't know my way around gmond, and that sounds like it might be a
> far-reaching change.
>
> Neil
>
>
>
>> Thanks,
>>
>> Bernard
>
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
