Specifications

on your system; on mine, it was put into
/usr/lib/ruby/gems/1.8/gem. Next, you need to add
the following to one or more of your environment
configuration files (either environment.rb or
one or more files in environments/*.rb) for your
Rails system:
require 'syslog_logger'
RAILS_DEFAULT_LOGGER = SyslogLogger.new
This, of course, loads the syslog_logger gem
and sets the default logger to a new instance
of SyslogLogger.
Now that you have told Rails to use syslog, you
must tell syslog what to do with the files that come
from Rails. I opened /etc/syslog.conf and added the
following lines to the bottom:
*.info /var/log/production.log
And yes, the documentation system says that
you can use a !rails tag before this line, or one like
it, to restrict logging to messages coming from Rails.
Unfortunately, this syntax does not appear to be
supported by Linux. So, this means production.log
will include messages from other programs and
facilities, not just Rails. That shouldn’t concern us
right now, although it might be an issue on a busy
machine with many services in active use.
Once you have modified syslog.conf in this
way, you can restart syslog.conf. Almost immedi-
ately, your production log should be stored to
/var/log/production.log. You can check this, of
course, with the following:
tail -f /var/log/production.log
Now, this logfile is similar in many ways to the
logfile you just eliminated from the log directory in
your application root. However, it is formatted in
such a way that the production log analyzer will be
able to find and perform calculations based on its
output. To analyze the logfile, type:
pl_analyze /var/log/production_log