i just checked in changed to ganglia 2.6.0 cvs. you can get a snapshot of the work to this point at http://matt-massie.com/ganglia/ganglia-2.6.0.tar.gz
here the new and improved (sane) way that unicast and multicast channels
are specified in gmond.
there are two new config file attributes "send_channels" and
"receive_channels". you can specify multiple channels and mix multicast
and unicast addresses.
the general format is <channel ip/name>:<channel port> (e.g.
239.2.11.71:8649) just like the data_sources in gmetad.
send_channels 192.168.0.34:8453 192.168.0.22 239.2.11.71:8649
would send all fresh metric values to three different channels. if
there is no port specified, then 8649 is assumed.
the "receive_channels" format is exactly the same but the way gmond
interprets a missing delimiter ':' is exactly opposite.
receive_channels 6667
would open a UDP server up on port 6667 and bind to INADDR_ANY. if you
wanted gmond to bind to a different hostname you could put...
receive_channels 127.0.0.1:6667
for example, would bind to the loopback address and listen on port 6667.
you can specify multicast address on the receive channels as well and
gmond will join that group and listen.
so, if you want gmond to behave exactly as it does by default in the
past (which is what it does if you don't specify any send or receive
channels)... you would write
send_channels 239.2.11.71:8649
receive_channels 239.2.11.71:8649
btw, mcast_channel and mcast_port still work... but they only update the
first channel in the send and receive list. don't mix mcast_* with
send/receive_channels (or you'll lose the mcast_* info or the first
channel in the list depending on the order in the config file).. but if
you don't use the new send/receive channels format.. you won't notice
any changes from old behavior.
gmond has been significantly altered. anyone who knew the old guts well
will welcome the changes. we are using two thread pools. one for
collecting and sending metric values. one for receiving data from other
gmond. the code is much more efficient and cleaner. it is also ready
for implementing plugins.
here is the API...
g3_thread_pool
g3_thread_pool_create(int num_worker_threads, int max_queue_size,
int do_not_block_when_full);
void g3_thread_pool_destroy(g3_thread_pool *pool);
int g3_run ( g3_thread_pool pool,
void (*routine)(void *arg), void *arg );
int g3_run_later( g3_thread_pool pool,
void (*routine)(void *arg), void *arg,
unsigned int secs, unsigned int usecs );
int g3_plugin_run( g3_thread_pool pool,
char *filename, char *function, void *arg );
int g3_plugin_run_later( g3_thread_pool pool,
char *filename, char *function, void *arg,
unsigned int secs, unsigned int usecs );
int g3_plugin_dir_run( g3_thread_pool pool,
char *dirname, char *function, void *arg );
int g3_plugin_dir_run_later( g3_thread_pool pool,
char *dirname, char *function, void *arg,
unsigned int secs, unsigned int usecs );
right now, i'm using the g3_run API calls... all I have to do it read a
few config file attributes and use g3_plugin_run instead. easy as pie.
take a look.
the only problem is that we'll have to reorganize the ${machine}.c
files. i don't want to open that can of worm just yet. i think it
makes sense to wait until we have the tree API up and running to allow
for a hierarchical metric space. we don't want to have to rewrite the
plugins more than once.
i guess one possibility is that we support plugins now for "custom"
metrics .. instead of using the gmetric mechanism. it would be much
more leaner and meaner. no more scripts and cron jobs .. you would be
running inside gmond just as if you were compiled in.
i hope you guys have a great weekend.
-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
