>>> On 9/13/2010 at 3:07 PM, in message
<da69eb53d9a64f0ab97a9454a66df...@peterphaald04f>, "Peter Phaal"
<peter.ph...@inmon.com> wrote:
> We have started this project and the pieces seem to be falling into place
> nicely. We already have the first metrics showing up in the web interface.
>
> The changes needed to implement sFlow support are contained entirely within
> the gmond.c file and are limited to the process_udp_recv_channel method.
>
> Adding the following lines to the gmond.conf file enables sFlow support:
> /* sFlow channel */
> /* Note: 6343 is the IANA registered port for the sFlow protocol */
> udp_recv_channel {
> port = 6343
> }
>
> Our initial goal is to populate all the standard metrics from libmetrics.
> Once we have that working, we will send a patch containing the changes to
> gmond.c.
>
Sorry to jump into this thread so late but I thought that I would throw my 2
cents in.
I finally got a chance to take a look at the code. I was able to compile it
but ran into some C99 issues with variable declarations. Once I got the code
to compile, I was able to take a closer look at what it was doing. From what I
could tell, it looks like the sflow integration is based around reading XDR
packets from an sflow agent and turning them into gmond spoofing metrics. My
first question after seeing this is why does this code have to be built into
gmond.c? Why can't it just do the same thing in a module that would be plugged
into gmond?
The reason why I ask this is because we went to a lot of work to pull all of
the metric gathering out of gmond and into modules (including all of the
standard metrics). Some of the main reasons for this is so that metric
gathering could be pluggable without having to affect the gmond code itself.
That way if a bug was ever found and fixed for a specific metrics, we wouldn't
have to re-release all of Ganglia just for one metric fix. Also, modules give
the user the ability to customize each gmond agent to conform to the specific
needs of the node where gmond is running. Regarding sflow, it seems that in
order to integrate the sflow metrics into the Ganglia monitoring system, only a
single gmond node needs to be configured to gather the sflow metrics. All of
the other gmond agents can continue to be configured and run as they were.
Given that, it would make more sense to integrate sflow as a module that could
be loaded under a single gmond agent rather than replacing all the gmond agents
or even upgrading just a single agent. It would also seem to follow the way
that other metric modules and spoofing modules have been implemented as well.
Implementing the sflow integration as a module would also allow it to change
whenever a newer version of sflow is released or whenever the sflow spec or
transport changes. A user could simply upgrade his ganglia sflow module and be
up to date with the latest spec without having to wait for the Ganglia project
to re-release ganglia.
Anyway, the more that I am learning about sflow and what it does especially in
relation to Ganglia and what it does, this all seems like a really cool idea.
I am looking forward to seeing this integration done especially if it is
through a pluggable module.
Brad
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
