Apache Security - Ivan Ristic [115]
SpreadDaemon 4803
CustomLog $access vcombined
The purpose of the spreadlogd daemon is to collect everything sent to the access group into a file. The configuration (spreadlogd.conf) is self-explanatory:
BufferSize = 65536
Spread {
Port = 4803
Log {
RewriteTimestamp = CommonLogFormat
Group = access
File = access_log
}
}
With this configuration in place, the three web servers send their logs to the Spread ring over the network. All members of the ring receive all messages, and the group names are used to differentiate one class of messages from another. One member of the ring is the logging daemon, and it writes the logs into a single file. The problem of cluster logging is elegantly solved.
The beauty of Spread is its flexibility. I have used only one logging group in the configuration above, but there can be any number of groups, each addressed to a different logging daemon. And it is not required to have only one logging daemon; two or more such daemons can be configured to log the same group, providing redundancy and increasing availability.
On top of all this, the authors mention speed improvements in the range of 20 to 30 percent for busy web servers. Though Spread does offer virtual hosting support, it does not work well with a large number of messaging groups. I do not see this as a problem since a sensible logging strategy is to use a logging format where the hostname is a part of the logging entry, and split logs into per-virtual host files on the logging server.
The module does not support error logging (because it cannot be done on Apache 1 without patching the core of the server) but a provided utility script error_log_spread.pl can be used, together with piped logging.
mod_log_spread only works with Apache 1 at the moment. This is not a problem since we have the piped logging route as a choice. Besides, as just mentioned, mod_log_spread does not support error logging, so you would have to use piped logging on a production system anyway. To support Apache 2, I have slightly improved the error_log_spread.pl utility script, adding a -c switch to force a copy of the logs to be stored on a local filesystem. This is necessary because error logs are often needed there on the server for diagnostic purposes. The switch makes sense only when used for the error log:
CustomLog "|/usr/local/apache/bin/log_spread.pl -g access" vcombined
ErrorLog "|/usr/local/apache/bin/log_spread.pl -g error -c /var/www/
logs/error_log"
Logging Strategies
After covering the mechanics of logging in detail, one question remains: which strategy do we apply? That depends on your situation and no single perfect solution exists. Use Table 8-8 as a guideline.
Table 8-8. Logging strategy choices
Logging strategy
Situations when strategy is appropriate
Writing logs to the filesystem
When there is only one machine or where each machine stands on its own.
If you are hosting static web sites and the web server is not viewed as a point of intrusion.
Database logging
You have a need for ad hoc queries. If you are afraid the logging database might become a bottleneck (benchmark first), then put logs onto the filesystem first and periodically feed them to the database.
Syslog logging
A syslog-based log centralization system is already in place.
Syslog logging with Syslog-NG (reliable, safe)
Logs must be transferred across network boundaries and plaintext transport is not acceptable.
Manual centralization (SCP, SFTP)
Logs must be transferred across network boundaries, but you cannot justify a full Syslog-NG system.
Spread toolkit
You have a cluster of servers where there are several servers running the same site.
All other situations that involve more than one machine.
Here is some general advice about logging:
Think about what you want from your logs and configure Apache accordingly.
Decide how long you want