Spread is a little painful to configure. 

Setup A - Standard Setup

Let's say we have 3 host - 2 webservers A and B and a log host C.  Let's
say that A,B, and C have interfaces 10.0.0.1, 10.0.0.2 and 10.0.0.3
respectively.  We have a spread daemon on each host (it's feasible to
run one only on the log host, but it really doesn't work well that way
at all.)


Spread setup:

Every machine in a spread ring's spread.conf file is identical.  If
you're running spread 3.12 they are:

	#spread.conf
	1
	3       10.0.0.255      3333
	A               10.0.0.1
	B               10.0.0.2
	C               10.0.0.3

This says that I have 1 ring with 3 hosts in it, 10.0.0.255 is the
broadcast udp address I'm using to send logs, and I'm doing it on port
3333.  Multicast also works in a similair way.  One note for multicast 
clients:  many Unices, notably Linux, will recieve muticast
announcements on all of their interfaces, but only send them through
one.  This can cause spread to go byzantine.  If you wish to set them
up to use multicast, make sure that all machines multicast routes are
bound to the interface that is listed in the spread.conf file.

If you're running spread 3.14, the config file is slightly different
but more self-explanatory.  The critical part is that they are all the
same.  You can also pad in hosts that you don't yet have but may want to
add at a later time (this makes dynamic addition easy.  e.g. just add a 
'D      10.0.0.4' line)

You should fire up all your spread daemons by running them as spread -c
<conffile>.  If 'A'is not the actual hostname of the machine, you
should add a '-n A' flag for A, so it knows for certain which element
of the file it's supposed to be.  Now you should check that they
work.  On two (or all) of teh machines, run 'user -s 3333'.  user is
the spread demo command line client.  In each of them type 'j test'
(this asks them all to join the group test.)  You should get something
back like: 

	User> j test

	User> 
	============================
	Received REGULAR membership for group test with 1 members, where I am
	member 0:
	#user#mg91
	grp id is -1062731514 971911129 1
	Due to the JOIN of #user#mg91

	User> 


	Now do a 's test' and type a message.  You should get (on all the
	machines that have joined test) the following:

	User> s test
	enter message: Blah blah blah
	
	User> 
	============================
	received SAFE message from #user#mg91, of type 1, (endian 0) to 1 groups 
	(15 bytes): Blah blah blah

	User> 


If you see that on all the joined machines, then your spread
configuration is working. 

basic mod_log_spread setup:

In your httpd.conf file, make sure that apache is talking to the
right daemon.  You should have the lines:

	SpreadDaemon 3333
	CustomLog $test common

This will tell apache to talk to the local spread daemon listening on
port 3333 and send logs to the group test.

Once restarted with those settings, you should be able to see  your
traffic on any of the 'user' clients still joined to test.

Once you have that, you configure spreadlogd.  Your spreadlogd.conf
should look like:

	#spreadlogd.conf
	Spread {
		Port = 3333
		Log {
			Group = "test"
			File = /my/log/dir/testlog
		}
	}

This says: listen to spread on the local damon on port 3333, join the
group test and write all access lines I recieve to /my/log/dir/testlog.

This is a very typical setup.  It works well when you know apriori all 
the different CustomLog statements you want to make.  This is often
not the case for virtual host setup, especially if you use something
like mod_vhost_alias which allows for dynamic runtime virtual server
addition.  Fortunately, so does mod_log_spread!

VirtualHost by Servername setup:

For a small number of virtual hosts (<100), the by Servername (or $#hostname)
distribution method works well.  Requests are sent to the group whose
name is the virtual servername as given by the Host: request header.
e.g. requests for www.lethargy.org are actually sp_multicasted to the
group named www.lethargy.org.  

On the webserver side, we set

	SpreadDaemon 3333
	CustomLog $#hostname common

As new hosts are added, no reconfiguration of the logging is necessary 
(so, if you're running mod_vhost_alias no reeconfiguration is needed
period.). 

spreadlogd does need to be aware of the changes, though.  For every
virtual host to be recorded, you need an additional Log section in the 
spreadlogd.conf
	
	Log {
		Group = "www.lethargy.org"
		File = /my/log/dir/access.lethargy
	}
	Log {
		Group = "my.other.domain"
		File = /my/other/log/dir/access
	}

Don't forget to hup spreadlogd after you change it's file (or move the 
log file for rotation.

VirtualHost by Servername Hash setup:

For a large number of virtual hosts, there is the hashing group
assignment (or $#vhost) distribution method.  In your httpd.conf set

	SpreadDaemon 3333
	CustomLog $#vhost common
	VhostLogHashSize 32

when a request comes in, mod_log_spread hashes the Host: header
servername to one of VhostLogHashSize buckets, and then sends them to
the group "apache-bucketnumber".  For every hash bucket, a separate
spreadlogd instance should be started, configure like:

	#spreadlog.conf.0
	Spread {
	Port = 3333
	Log {
		Group = "apache-0000"
		VhostDir = /my/log/dir
	}
	}

	#spreadlog.conf.1
	Spread {
	Port = 3333
	Log {
		Group = "apache-0001"
		VhostDir = /my/other/log/dir
	}
	}

Every message it then recieves it records to the file
"/my/log/dir/<servername>", e.g. if www.letahrgy.org hashes to bucket
0, then all requests for it, will be written out to
"/my/log/dir/www.lethargy.org".  Since a given process is bounded in
the number of open files it can maintain by the value of NR_OPEN on the
system, and there are also system-wide open file caps, for large
configurations multiple log hosts shuld be run, each handling a
segment of hash groups.  On many systems it is also possible to raise
NR_OPEN by recompiling the kernel.

To deal with imperfect distribution by the hash function, a good
formula for deriving the VhostLogHashSize is ((# of vhosts) * 2)/(NR_OPEN)

For small configurations, 
	VhostLogHashSize 1 
will write all your vhosts to a single directory with no muss or fuss.