Lumber

Lumber tries to make it easy to use the more robust log4r logging system within your rails application. To do this it sets up log4r configuration from a yml file, and provides utility methods for adding a :logger accessor to classes dynamically as they get created. In the default setup shown below, calls to logger from a model/controller/mailer, will include that classes name in the log output.

To use it in a rails project:

add lumber to your Gemfile
bundle install
run the lumber generator, rails generate lumber, to get a basic config/log4r.yml
enable lumber in your rails project

To enable lumber in your rails project, add to your config/application.rb:

# To expose custom variables in log4r.yml
# config.lumber.some_option = "some_value
# you can set default_log_level here, config/environments/*.rb or in config/log4r.yml
# config.log_level = :debug
# enabling lumber sets config.logger to Log4r::Logger['rails']
config.lumber.enabled = true

You should be able to use lumber in a non-rails project too, but you will have to manually call Lumber.init - see the docs for details on parameters:

# before Rails::Initializer.run
#
require 'lumber'
Lumber.init(:root => "/my/project", :env => "development")

# Setup parent loggers for some known rails Base classes.  Classes that inherit
# from these will have their logger as a parent so you can configure logging for
# subtrees of classes in log4r.yml
Lumber.setup_logger_hierarchy("ActiveRecord::Base", "rails::models")
Lumber.setup_logger_hierarchy("ActionController::Base", "rails::controllers")
Lumber.setup_logger_hierarchy("ActionMailer::Base", "rails::mailers")

# If you really want, you can make all classes have a logger
# Lumber.setup_logger_hierarchy("Object", "root::object")

Additionally, you can also add loggers to individual classes by including the Lumber::LoggerSupport module

class Foo
  include Lumber::LoggerSupport
end

and Foo.logger/Foo.new.logger will log to a logger named "rails::Foo". This creates a hierarchy of loggers for classes nested within modules, so you can use the namespace to enable/disable loggers.

The logger concern used by Lumber is customizeable:

module MyLoggerConcern
  extend ActiveSupport::Concern
  include Lumber::LoggerSupport

  # an example custom logging function
  def log_error(error)
    logger.error("ERROR: #{error}")
  end
end

This custom logger concern should be registered in an initializer so that it is available dynamically:

# before Rails::Initializer.run
#
require 'lumber'
Lumber.logger_concern = MyLoggerConcern

If you want to change the log level for a different environment, you can do so in log4r.yml or by using the standard rails "config.log_level" setting in config/environments/.rb

# Set info as the default log level for production
config.log_level = :info

Lumber also comes with a Sinatra UI for dynamically overriding log levels at runtime. To use it, just run Lumber::Server as a rack application. The easiest way to do this is to map it to a route in your rails routes.rb (make sure you password protect it):

require 'lumber/server'
mount Lumber::Server, :at => "/lumber"

This will allow you to temporarily set lower log levels for specific loggers - e.g. if you want a specific model to have DEBUG logging for the next hour. Note that this behavior is enabled by a monitor thread running in your process, so if you want to be able to change the log levels for forked subprocesses (resque, passenger, unicorn, etc), you'll need to restart that thread in an after fork hook by calling Lumber::LevelUtil.start_monitor or use Lumber::LevelUtil.activate_levels for a oneoff activation without the thread.

lumber

Development

Runtime

Lumber

Copyright