Rogger

Description

Rogger is a remote logging daemon that organizes the log messages it receives into an environment/category/service directory structure. It plays well with Logger and is ideal for a home network running Ruby apps (or other languages, for that matter) on multiple OSes.

Setting up Rogger

Installation

Rogger is available as a gem from RubyForge. Install with:

sudo gem install -r rogger

The config file

The config file is located in the directory where the gem is installed, of all places. It’s called rogger.config.yml. Here’s a sample config file:

port: 19003
directory: "/var/log/rogger"
flush_wait: 10

Setting up the log directory

First, make the directory listed in the config file:

export ROGGER_DIR=$(ruby -e 'require "rubygems"; gem "rogger"; require "serene_daemons_rogger"; s = Serene::Daemons::Rogger::Rogger.new; puts s.config["directory"]')
sudo mkdir -p $ROGGER_DIR

Then, change the permissions so that the user running rogger has write access to $ROGGER_DIR.

Running the test

The user who launches the unit test will need write permission to the ‘directory’ in the rogger.config.yml file. The port listed in the config file will also have to be open. So, don’t have any other instances of Rogger running when you launch the test.

gem check rogger --test

If the unit test fails, the program will fail, guaranteed.

Example client

Connecting to Rogger and identifying your program couldn’t be easier, or less secure :) Everything is sent in plain text, and Rogger doesn’t use authentication of any sort.

Rogger only requires that the environment/category/service values used to identify your program be alphanumeric. In the example below, the client will identify itself as the service ‘website’ which is part of the ‘tools’ category, running currently in the ‘prod’ environment:

require 'logger'
rogger = TCPSocket.new("127.0.0.1", 19003)
rogger.puts("service=website,environment=prod,category=tools")

The Logger can then be instantiated and handed the TCPSocket object, rogger:

log = Logger.new(rogger)
log.level = Logger::DEBUG
log.info("Testing info logger to rogger")

Closing the connection should be done via the Logger.

log.close

Hopefully, everything that was part of Logger will still work the same. Thank goodness for Ruby.

Where logs go

The path to a log file can be found by combining the ‘directory’ from rogger.config.yml with the environment, category and service name of the client program, plus today’s date. The identifier

client_identifier = "service=website,environment=prod,category=tools"

would bring about logfiles in

@config['directory'] + "/prod/tools/website/"

Reading the logfiles

There is no support in Rogger itself for identifying what instance of the client program is running. So, if your program has lots of users, or even if it’s only run multiple times during a day by one user, Rogger won’t help you to identify when a log started and when it ended, nor will it keep log lines from the same environment/category/service from interfering with one another in the same log file.

When log lines come in to Rogger, it buffers them and waits until the number of seconds in the config file (@config) has been reached, then it spits them all out into files that bear today’s date, in YYYYMMDD format.

It’s up to the client program to format its logs well.

Rogger’s own logfile

Rogger has its own logfile, too. It’s stored in the same place as the other logs it writes. Rogger considers itself to be part of the “prod” environment and in the “daemons” category.

@config['directory'] + "/prod/daemons/rogger/"

Rotating logs

Rogger does not rotate its logs. You may have to come up with your own way of removing logfiles you don’t need anymore or truncating ones that get too big.

Support

To request support or report a bug, visit rogger.rubyforge.org