I just commited changes to the website and new disk metrics. The website
changes primarily take advantage of the new metric attributes that Matt
added recently.
The disk metrics will report local disk sizes. Although gmetric scripts
do exist for this purpose, the new metrics are coded entirely
Hoo boy, who'd have thought it would take so long to make world a couple
times with a couple different compilers on an O2?
My monitoring core CVS checkout is now running on my test box with no
problems. It even reports the MTU metric properly using the code shoveled
from gmond/machines/linux.
Almost all of my compilation problems on IRIX and some on Solaris were
directly attributable to GNU autoconf/automake/aclocal/autoheader/libtool
issues. Upgrading and downgrading to different versions and
tinkering-by-hand turned out to be the fix...
Note that version 1.4 of automake (if memo
Jason A. Smith wrote:
I have a few questions about ganglia development. I am using ganglia on
RedHat 7.x i386 here.
1. I tried the new network metrics that are in the latest cvs version
of the monitoring-core module and was wondering what happens on a dual
NIC computer, is just the first inter
preston-
i had a strange problem yesterday where i was getting autoconf errors.
i'm using Autoconf version 2.13 to generate the makefiles et al. we might
want to look at how to handle derived files correctly in CVS. can you try
the latest CVS to see if my changes fixed the problem?
-matt
T
I have a few questions about ganglia development. I am using ganglia on
RedHat 7.x i386 here.
1. I tried the new network metrics that are in the latest cvs version
of the monitoring-core module and was wondering what happens on a dual
NIC computer, is just the first interface counted or does it
On Thu, Aug 15, 2002 at 03:11:34PM +0200, Leif Nixon ([EMAIL PROTECTED]) wrote:
> A tentative fix would be to instead count the number of lines
> starting with "processor" in /proc/cpuinfo.
>
Done.
My cvs log:
Added mtu code for freebsd and aix, since it won't compile
without it there.
Pat
James Braid wrote:
My Origin 2k didn't like it either. Wouldn't compile to start with, so
what I have done, is tack the linux.c mtu bits onto the end of the Irix
file. It didn't like that (seg faulted just after doing something with
mtu_func).
I then gave mtu_func a bit of a hack and just made i
On Thu, Aug 15, 2002 at 03:11:34PM +0200, Leif Nixon ([EMAIL PROTECTED]) wrote:
> Hi,
>
> I was a bit surprised when Ganglia reported that a couple of my clusters
> have a grand total of zero CPUs.
>
> Seems monitor-core/gmond/machines/linux.c uses a buggy method
> to determine the number of proc
On Tue, Aug 13, 2002 at 11:01:26AM -0700, matt massie ([EMAIL PROTECTED]) wrote:
> > Preston has been quiet so I am assuming that all is well with CVS on his
> > platforms...
>
> yeh i think so. i'm sure preston wouldn't hesitate to let us know
> otherwise. the BSD AIX universes still happy?
>
Hi,
I was a bit surprised when Ganglia reported that a couple of my clusters
have a grand total of zero CPUs.
Seems monitor-core/gmond/machines/linux.c uses a buggy method
to determine the number of processors in a x86 machine; it counts
the number of lines starting with "cpu" in /proc/stat and s
My Origin 2k didn't like it either. Wouldn't compile to start with, so
what I have done, is tack the linux.c mtu bits onto the end of the Irix
file. It didn't like that (seg faulted just after doing something with
mtu_func).
I then gave mtu_func a bit of a hack and just made it return 0gmond
s
> james et al-
>
> i *think* i've made gmond more bullet-proof to problems
> caused when a client prematurely closes its connection to the
> XML port. this will hopefully fix the problem where gstat
> can crash gmond. let me know otherwise.
Awesome, it works fine (at least on Irix, havent te
13 matches
Mail list logo
