>I believe the graphs should be template driven, somewhat like the
>template pages.
I agree with Jesse that this is rather difficult with current code.
>- whether or not to show stats in the legend
In my graph.php I have (like in trunk):
# Make small graphs (host list) cleaner by removing the t
> IMO the graphs are already to cluttered for a quick overview and I have
>ideas for adding even more clutter (that matters to me, like the date the
Good idea to add the end date/time to graphs larger than default (like when you
zoom an individual graph to save it). I think we can do this in gra
>> Windows users are looking at the figure and thinking that `Avg
>> Utilization' refers to CPU utilization (from the cpu_report graph).
>>
>> Maybe both are needed:
>>
>> cluster_util_load: displayed as `Avg Utilization (Load)'
>>
>> cluster_util_cpu: displayed as `Avg Utilization (CPU)'
>>
>> Can
>From: Carlo Marcelo Arenas Belon [mailto:[EMAIL PROTECTED]
>I am not asking about why 1 patch was provided (which I agree is really
>useful
>for testing) but on why the STATUS change doesn't instead list all patches
>that are needed (at least from my initial merge attempts based on your
>instruc
Thanks Jesse,
>I like it in general. Removing the text from the small graphs makes
>them less cluttered, and that a good thing (and I was skeptical at
>first).
>
>There are a few alignment issues, and altering the height of the
>graphs, but nothing major.
And now you have mostly fixed these, tha
and metrics. I suppose it could be a configurable option, but
that would make the code more complicated.
-twitham
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:ganglia-
>[EMAIL PROTECTED] On Behalf Of Witham, Timothy D
>Sent: Wednesday, September 10, 2008 2:24 PM
>
>I suggest that we move the infrequently change variables out of
>conf.php, and into a different file completely, named something like
>"config-default.php"
Great idea! In fact, I already did this since all my gmetad nodes are
configured identical except for $gmetad_root/$rrds and $ganglia_port
>From: Seth Graham [mailto:[EMAIL PROTECTED]
>Sent: Friday, August 22, 2008 3:50 PM
>But ganglia's best feature (well, to me) is the availability of the xml
>data. It makes it extremely easy to write your own parser, and arrange
>the data however you see fit. I have two interfaces written that rel
Carlo said:
>> bz#176 custom time range with optional calendar widget
>
>nice work and good to see it is making progress for inclusion in future
>releases with optional support for the calendar widget.
I've been using it for many months but I guess no one liked it. Probably
because it included
>Thanks for cleaning the code up, you got rid of the warnings, etc.
>from error_log and the layout is much better. I still have some minor
>nitpick issues with layout/spacing, but that can be dealt with later
>:-). BTW, I think you get rid of the "Clear" button by accident?
Actually, I did this
Hi guys,
I have updated a few web frontend patches to apply cleanly on current trunk for
your consideration / discussion. They are on bugzilla.ganglia.info:
bz#176 custom time range with optional calendar widget
bz#184 show and zoom 4 reports on the current grid
bz#193 put averages on all graph
>> Reading through the backlog, what you guys really want is
>> something similar to zeroconf/bonjour -- have any of you
>> thought of integrating it with Ganglia?
>>
>> http://developer.apple.com/opensource/internet/bonjour.html
>>
>> This is cross-platform, works on Mac OSX, UNIX, Windows.
>>
>>
>still, how does a restart happen or how is new configuration detected by
>gmond? There would still have to be something that pokes gmond to tell it
>to restart. And if that is the case, then we are back to why not just use
>an existing configuration management service.
Exactly. Since the propo
> Ganglia does not need an auto configuration tool.
> Updated configuration files in large clusters has been addressed by several
> other mechanisms.
This was not my problem. My problem was hundreds of small to medium clusters,
constantly changing. Static or manual configuration could not ke
>do some complicated IRC dances (that Timothy has yet to perform as he
would
>most likely have to violate some company policy to do so unless taking
a
>day off to do it from home).
Hahaha. Mostly I have just been way too busy, and haven't done IRC for
years, and would have to look up the company
>What happens when you have multiple clusters? Each node needs to know
>which cluster name and multicast address to use. In a huge
>organisation, it is not feasible for every node to join the same
>multicast group. In some clusters, not all nodes are on a shared
>multicast segment. So the defau
>Either way, submit patches via bugzilla.ganglia.info and we'll take it
>from there.
When do bugzilla patches get considered for inclusion in trunk or
stable? It seems like the longer you wait the harder it is to apply the
patches. I always use patches from bz#38, 92, 176, 184 and 186:
http://b
>Please have a look at this patch, perhaps it'll help with your
endeavor:
>
>http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=176
I really like that patch too. :-)
>On Wed, Apr 16, 2008 at 2:01 PM, Rich Paul <[EMAIL PROTECTED]>
wrote:
>> I've been hacking on ganglia, to add the abil
Carlo said:
> Martin said:
>> There is a fix in linux/metrics.c r1029 that bz#180 . This should
go
>into 3.0.8. The fix is relatively nice in trunk, but more ugly in 3.0.x
due
>to the code duplication in the networking metrics. I see two possible
>ways:
>>
>> a) we backport only r1029, even if
>So in other words, we could add some addition configuration to the
>port directive to specify it as an XML_port (currently supported) or a
>delta_port (new type). The other option would be to just add a
delta_port
>configuration directive and add the functionality. I am assuming that
as
>gmetad
>It looks like I missed revisions 1206 and 1215. I've updated the
>patch. Please review again.
Yes, I believe the patch is complete now and will resolve bz#76 for
3.0.x.
+1. Thanks Bernard!
-twitham
-
This SF.net email
It breaks the /?filter=summary but that is easily fixed by including
r1215:
Index: server.c
===
--- server.c(revision 1185)
+++ server.c(revision 1215)
@@ -121,13 +121,9 @@
source->hosts_up, source->hosts_down);
if
>So what I ended up doing is set up another layer of gmetad between HQ
>and the remote grid and that new layer would simply send summary
>information back to HQ, which reduced the amount of traffic by a lot.
Correct. The gmetad pulling from clusters must get all the data from
all hosts since it l
>From: Carlo Marcelo Arenas Belon [mailto:[EMAIL PROTECTED]
>gmetad hierarchical setups has several areas for efficiency
improvement.
>this one (doing summaries from partial summaries in the leafs) being
one
>that was on the "TODO" list as a nice to have for a 3.1 release from
what
>I recall, and
Bernard said:
>I am running gmetad r1199 on a server which has one data_source which
is a server running gmetad 3.0.7 via port 8651.
>In the webfrontend, the summary "CPUs Total" shows nothing, however,
the "CPUs Total" for the data_source running gmetad 3.0.7 is correct.
I actually had done the
r1170 passes my tests. Thanks!
-twitham
-Original Message-
From: Carlo Marcelo Arenas Belon [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 29, 2008 3:31 AM
To: Witham, Timothy D
Cc: Bernard Li; ganglia-developers@lists.sourceforge.net; Brad Nicholes;
Martin Knoblauch
Subject: Re
> On a somewhat related note, I have often wondered what the CPU or
Network > graphs might look like at the higher grid levels. Obviously
we can't add > any more than 2 graphs to the page; it would get too
wide.
Hmmm, with Bernard's separate template for the $self top node, you could
show all 4 r
On a somewhat related note, I have often wondered what the CPU or
Network graphs might look like at the higher grid levels. Obviously we
can't add any more than 2 graphs to the page; it would get too wide.
Here's a simple hack to add a couple small clickable words instead.
-twitham
Index: meta_v
Bernard said:
> My patch is bit more involved, but will allow you to simply click on
> the graph to zoom in (instead of a '*' which was artificially added):
Ah, excellent approach, I like it better than mine! With a slight hack,
we can do it much simpler with no new blocks, as shown below. If t
Hi Carlo,
>> Looks like gmetad in trunk is broken. When I request summary
>> information it segfaults:
>the newer implementation from r1142 shouldn't segfault anymore.
No seg fault for me on Linux and I agree that is a cleaner place to put
the lock. I had considered that but thought it might l
Bernard Li [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 2:59 PM
To: Carlo Marcelo Arenas Belon
Cc: Witham, Timothy D; ganglia-developers@lists.sourceforge.net; Brad
Nicholes; Martin Knoblauch
Subject: Re: [Ganglia-developers] Commit bugfix for bz #76 into 3.0.X
Hi guys:
On Thu, Mar 27,
It has run all these years without the mutex, so I think reporting
usually complete data as it always has would be a better default than
not reporting at all. I'm not sure if there is a guarantee that the
mutex has been initialized before we get a TCP connection so I put the
conditional around it
> i think the current code also allows for gmetad hierarchies to do the
summary
> right, because 3.1 will use (unless I misunderstood the code) float
types for
> memory metrics anyway, but haven't yet test that.
> do you have any probe otherwise?
Imagine that I have many grids around the globe a
Marcelo Arenas Belon [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2008 1:19 PM
To: Witham, Timothy D
Cc: ganglia-developers@lists.sourceforge.net; Brad Nicholes
Subject: Re: [Ganglia-developers] bug#128: combine integers and floats
into one double sum
On Thu, Mar 20, 2008 at 10:26:36AM
Arenas Belon [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2008 2:07 AM
To: Witham, Timothy D
Cc: Brad Nicholes; ganglia-developers@lists.sourceforge.net
Subject: Re: [Ganglia-developers] [Ganglia-general] Time to create
the3.1.xstable branch...
On Tue, Mar 18, 2008 at 12:11:44PM -0700
Sent: Monday, March 17, 2008 5:20 PM
To: Witham, Timothy D; ganglia-developers@lists.sourceforge.net
Subject: Re: [Ganglia-developers] [Ganglia-general] Time to create
the3.1.xstable branch...
>>> On 3/14/2008 at 10:04 AM, in message
<[EMAIL PROTECTED]>,
"Witham, Timothy D" &
I haven't used 3.1 yet but I see memory changes to float. That is good.
However, old 3.0 gmonds could still be reporting integers. Are you sure
that gmetad can successfully get one correct total from two data types?
Please read bug#128 and see if it makes sense to change gmetad to do
sums as do
37 matches
Mail list logo