guys- here are the latest changes that i've made to ganglia. i put a tarball of 2.5.7 at http://matt-massie.com/ganglia/ .
first off, i've moved all the web frontend PHP stuff into the main distribution (directory ./web). this is going to simplify maintenance considerably and make sure the versions are in sync. we won't get questions like "when are you going to release version 2.5.7 of the web frontend?" when we release 2.5.7 of the monitoring core. i've updated conf.php to follow the version of the rest of the distribution. this will ensure that the upgrade link at the bottom of the page is always correct. one side effect of this change is that the name of the rpm will change. the web frontend is now a subpackage of the main ganglia-monitor-core distribution. so our new subpackages are ganglia-monitor-core-gmond ganglia-monitor-core-gmetad ganglia-monitor-core-lib ganglia-monitor-core-web the ganglia-monitor-core-web rpm understands that it obsoletes the old ganglia-webfrontend rpm. in short, it's just a name change. building the RPMs just takes a % rpmbuild -ta --target noarch,i386 ganglia-monitor-core-x.x.x.tar.gz since the web stuff is architecture independent. enough about packaging. i've also built xml compression (using zlib) into all parts of ganglia. the configure script checks for zlib and if it's not found outputs nice instructions on how to get it. zlib is statically linked so we don't need to worry about having it installed on every node in your monitoring space. here is how i have it working now.. but it's fluid and i'm open to suggestions. both gmetad and gmond have a new configuration tag "xml_compression_level" which can be set from 0 (no compression) to 9 (best compression). the default compression level for gmond is 6 and default for gmetad is 0. my logic here is that i think many of you are using a single tier monitoring configuration. it doesn't make sense to have gmetad output compressed XML when the data is only read locally. in configurations that use a multi-tier approach, you simply modify /etc/gmetad.conf and add the line xml_compression_level 6 and edit conf.php from $use_compression = false; to $use_compression = true; and everything is ready to go. adding compression is backward compatible too. all 2.5.7 components can read compressed/uncompressed data regardless of the compression setting. the compression setting only effects how they share their xml, not what they can read. note: the web frontend takes a hit if compression is on. not just because it has to decompress the data but also because PHP does not support on-the-fly decompression over the wire. instead, i had to write the compressed data to a temporary file and pull it in from there. don't worry though, if the compression is off then it parses the XML on the fly (no temp files). another note.. i know how much steve wagner likes to read raw XML and that is still possible. before.. you just ran 'telnet localhost 8649' for example and your screen was filled with glorious XML. of course, if the compression is turned on you will get no-so-human-readable compressed data. the easy work around is to install netcat (http://netcat.sf.net/) and run % nc localhost 8649 | gunzip that's it (if you're running linux it's very likely you already have netcat installed). the ganglia library has been updated to read both compressed and raw XML. running gexec/gstat for example will work the same as before whether it gets compressed or raw XML. i also fixed the annoying bug where gstat segfaulted when it couldn't connect to a ganglia data source. i also have 2.5.7 compiling nicely on cygwin (not even a single error). the problem though is that cygwin doesn't support multicast right now. that's ok though.. because soon ganglia will be much flexible in that regard and allow you to use unicast as well (once we support unicast.. we will automatically be supporting windows too). let me know what you think about the solaris code martin wrote. i'm really glad it going to be part of the 2.5.7 release. i want to put in one last bug fix for 2.5.7. gmetad has a problem where DNS can really screw it up. these DNS problems can cause really really ugly graphs with huge gaps. the problem works like this.. all the rrds are put in a case-sensitive unix filesystem (/var/lib/ganglia/rrds). the rrds are placed in a hierarchical structure keyed on the name of the machine. if DNS goes down, gmetad uses the IP address of the machine. if DNS is up, it will use the name. there's more. DNS is case-sensitive so it can say the name of the host is host01.Berkeley.EDU or host01.berkeley.edu. i'm going to start work on a solution now and get back to you all very soon. i want to share my current motivation with you to let you know where i'm coming from. my primary funding is now coming from the planet-lab project (http://www.planet-lab.org/). because of this, you're going to see more effort put into making ganglia more robust, efficient and manageable in very distributed environments. i'm also going to focus on moving ganglia from being simply a sysadmins tool and making it a grid/cluster developers tool as well (ganglia-monitor-core-lib will be getting a face lift). let me know whacha think -matt -- mobius strippers never show you their backside pgp fingerprint A7C2 3C2F 8445 AD3C 135E F40B 242A 5984 ACBC 91D3
signature.asc
Description: This is a digitally signed message part