guys- there is a new 2.6.0. snapshot available at http://matt-massie.com/ganglia/ganglia-monitor-core-2.6.0.200412021149.tar.gz
i've tested this new snapshot on linux and cygwin (meaning i compiled and ran gmond).
when you run a "cvs update" you will see what appears to be dramatic changes but it's not really.
i've added tha apache runtime (apr) to ./srclib. i've also added a file ./lib/apr_net.c which will serve as the api glue to the apr socket functions. apr doesn't support multicast (for now). i've added multicast support (and passed the code along to the apache project).
i haven't yet set up gmond/gmetad to use the new socket library. i've also created a XDR protocol description file at ./lib/protocol.x.this protocol description is passed to the "rpcgen" protocol compiling to create the XDR stub functions for passing ganglia messages (./lib/protocol_xdr.c && ./lib/protocol.h). if you take a minute to read ./lib/protocol.x you'll see that i also put in support for 2.5.x XDR messages. this new protocol description will prevent any backward compatibility problems in the future.
i'm not completely married to the protocol that i've developed in ./lib/protocol.x and welcome any feedback.
i've also created a ./tests directory which will hold our regression tests in the future. currently, there are two programs built in ./tests: xdrclient and xdrserver. these programs test the XDR protocol that i'm working on. you can see that they are pretty simple programs... xdrclient packs up a gangliaMessage and sends it to STDOUT while xdrserver reads from STDIN and unpacks a gangliaMessage. if you look at the code you'll see how using a protocol compiler will make ganglia much easier to work on.
when analyzing ganglia's network footprint, i learned that we really needed a way to pack multiple metric message together. before, each metric was sent in individual messages and each message had its own IP header (20 bytes) and UDP header (8 bytes). even though most 2.5.x message are 8 bytes in size (4 byte key and 4 byte value) the total size is 36 bytes/ message.
the current protocol that i propose has the following advantages:1. all necessary information is contained in the network message (ie. you don't need a large static metric array compiled into your program to read it). 2. a new "quality" attribute has been added to the ganglia message. this allows you to tag the data as normal, warning, alert, etc. this will allow for real-time events to occur in response to specific metric states (email me when the mail server goes down). 3. as new message formats are added in the future... older message formats will still be easily processed. (i'm using the old 2.5.x "key" integer as a format enum to a disriminant union... the key tell you how to process the rest of the message). 4. even being very verbose and supporting alerts it will only increase bandwidth usage by very little and dramatically reduce the number of packets sent.
i've used xdrclient and xdrserver to collect some measurements.
(bytes including headers)
#metrics new way old way
1 92 36
2 112 72
3 132 108
4 152 144
5 172 180
6 192 216
7 212 252
8 232 288
9 252 324
10 272 360
this table shows home much network bandwidth is used to send n number of
metrics. for example... it is wanted to send cpu_user, cpu_nice,
cpu_system, and cpu_idle... with the new message format.. i would have
to send 152 bytes (in 1 packet) and with the old format i would send 144
bytes (in 4 packets).
i'm certain i can reduce the new format bandwidth costs even more. again.. any feedback on the proposed XDR protocol would be very welcome.
-matt
--
PGP fingerprint 'A7C2 3C2F 8445 AD3C 135E F40B 242A 5984 ACBC 91D3'
They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.
--Benjamin Franklin, Historical Review of Pennsylvania, 1759
signature.asc
Description: OpenPGP digital signature
