Bernard,
On Mar 4, 2011, at 3:30 PM, Bernard Li wrote:
> Hi Neil:
>
> On Fri, Mar 4, 2011 at 1:35 PM, Neil McKee wrote:
>
>> OK, I added some commented-out lines to lib/default_conf.h.in, and checked
>> in the changes in that directory. Should be OK now(?)
>
> Looks fine.
>
> BTW, did w
Hi Neil:
On Fri, Mar 4, 2011 at 1:35 PM, Neil McKee wrote:
> OK, I added some commented-out lines to lib/default_conf.h.in, and checked
> in the changes in that directory. Should be OK now(?)
Looks fine.
BTW, did we already decide that 'accept_all_physical' is no longer a
configurable opti
OK, I added some commented-out lines to lib/default_conf.h.in, and checked in
the changes in that directory. Should be OK now(?)
Thanks for catching my mistake.
Neil
On Mar 4, 2011, at 12:40 PM, Bernard Li wrote:
> Hi Neil:
>
> On Fri, Mar 4, 2011 at 11:25 AM, Neil McKee wrote:
>
>> I ad
Hi Neil:
On Fri, Mar 4, 2011 at 11:25 AM, Neil McKee wrote:
> I added documentation to the gmond/conf.pod file, but I don't know if/how
> this gets into the man page(?)
Yes, that gets converted to gmond.conf.5 in the Makefile:
https://sourceforge.net/apps/trac/ganglia/browser/trunk/monitor-c
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 and you also wanted
to see any VMs that m
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 wrote:
>
>> There are three metrics to draw particular attention to:
>>
>>
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 wrote:
> There are three metrics to draw particular attention to:
>
> 1. System UUID
I noticed that on my Windows host, UUID is
The code is stable enough for release, yes. It's certainly a big improvement
on the old code. It doesn't do anything different in terms of memory
allocation, and it's been running here for a week with no problems. I'm
hoping you'll check it into the 3.2 branch as well.
I was thinking that
Hi Neil:
On Mon, Feb 21, 2011 at 3:09 PM, Neil McKee wrote:
> Here is essentially the same patch, but this time with a small bugfix to
> remove a few lines that were only there for testing.
Thanks for the patch.
Since we've agreed that it would be a bad idea to set values to 0 when
they aren
Here is essentially the same patch, but this time with a small bugfix to
remove a few lines that were only there for testing.
ganglia_sflow_20110221.patch.gz
Description: GNU Zip compressed data
On Feb 17, 2011, at 2:22 PM, Neil McKee wrote:
> Attached is a patch (against trunk rev 2479) t
Hi Neil:
On Tue, Feb 15, 2011 at 11:43 AM, Bernard Li wrote:
> I've changed my mind after hearing other people's thoughts on the
> matter. The correct fix should be in the frontend code. I'm already
> working on it for cpu_report and mem_report. However, it would be
> tricky for the load_* me
Hi Neil:
On Fri, Feb 11, 2011 at 2:26 PM, Neil McKee wrote:
> It might be helpful to have commit privileges for minor bugfixes, yes.
> Although I wouldn't use it for bigger changes that require consensus.
Yeah, that would be the idea. Bigger changes should be discussed
prior to being check
Hi Neil:
On Thu, Feb 10, 2011 at 8:52 PM, Neil McKee wrote:
> OK, I cleared out everything under /var/lib/ganglia/rrds/. Now I see the
> problem. In the short term I guess gmond/sflow.c could just submit zeros
> for the missing metrics instead of leaving them out altogether(?) However in
> Glad to hear it. Is there is anything else you/they would like to see added
> in the
> future too? (e.g. how about real-time performance stats from apache
> web-servers?
> See http://mod-sflow.googlecode.com)
Yes, Apache web server stats are definitely on their list of wanted metrics
alon
ws cluster names assigned to them. Was this the intention? If so, I like
> it.
>
Yes. Exactly.
Neil
> Regards,
> Nick
>
> -Original Message-
> From: ext Neil McKee [mailto:neil.mc...@inmon.com]
> Sent: Saturday, February 12, 2011 7:56 AM
> To: ganglia-deve
m. Was this the intention? If so, I like it.
Regards,
Nick
-Original Message-
From: ext Neil McKee [mailto:neil.mc...@inmon.com]
Sent: Saturday, February 12, 2011 7:56 AM
To: ganglia-developers@lists.sourceforge.net
Subject: Re: [Ganglia-developers] hsflowd for Windows + Ganglia webfrontend
Here is the patch I was referring to. It allows you to put something like this
in your gmond.conf:
sflow {
null_int = 0
null_float = 0.0
}
and then if a fields like cpu_nice is missing (as in the Windows hsflowd) we'll
submit 0.0 instead of leaving it out. This is a work-around for the p
It might be helpful to have commit privileges for minor bugfixes, yes.
Although I wouldn't use it for bigger changes that require consensus.
I'm working on a bigger patch that will add an sflow { } configuration block so
we can have options to control the following:
- the sflow udp port
- wh
Hi Neil:
Argh, Gmail always mess up inline patches... anyways, I've fixed it
manually and checked it in:
https://sourceforge.net/apps/trac/ganglia/changeset/2473
Do you want commit rights to our SVN repo so that you could fix this
yourself in the future? :)
Thanks,
Bernard
On Thu, Feb 10, 20
I didn't realize that "gmond_started" was meant to go with every
heatbeat-message. Below is a patch.
Neil
[root@ganglia gmond]# svn diff sflow.c
Index: sflow.c
===
--- sflow.c (revision 2471)
+++ sflow.c (working copy)
@@ -
OK, I cleared out everything under /var/lib/ganglia/rrds/. Now I see the
problem. In the short term I guess gmond/sflow.c could just submit zeros for
the missing metrics instead of leaving them out altogether(?) However in the
long term it would seem more elegant to fix this in the place w
P.S. It looks like GMOND_STARTED=0 for the Windows host -- should I file a bug?
Thanks,
Bernard
On Thu, Feb 10, 2011 at 5:21 PM, Bernard Li wrote:
> Hi Neil:
>
> On Thu, Feb 10, 2011 at 5:05 PM, Neil McKee wrote:
>
>> That's odd, the CPU and MEM charts are working OK for me. It's just the
>
Hi Neil:
On Thu, Feb 10, 2011 at 5:05 PM, Neil McKee wrote:
> That's odd, the CPU and MEM charts are working OK for me. It's just the
> load-avg that is missing (which causes the host to be marked "down").
You'll likely need to nuke your old rrd files to see the error.
For Windows, mem_shar
That's odd, the CPU and MEM charts are working OK for me. It's just the
load-avg that is missing (which causes the host to be marked "down").
For troubleshooting, if you intercept the sFlow feed with sflowtool
(http://www.inmon.com/technology/sflowTools.php) then you can see what the
numbers
Hi all:
I just tested hsflowd 1.11 on Windows with the latest code in trunk
and run into some issues with the frontend where certain graphs like
load_, cpu_ and mem_ reports are not showing up.
The reason is probably due to the fact that a recent change in the
sflow integration code where unsuppo
25 matches
Mail list logo
