Clogger 0.0.4 - configurable request logging for Rack

Clogger is Rack middleware for logging HTTP requests. The log format
is customizable so you can specify exactly which fields to log.

Changes:

0.0.4 / 2009-09-02

The pure Ruby version now escapes with uppercase A-F
characters to match nginx log output. There are now extra
checks against badly behaving Rack applications and 500
errors will be logged before TypeError is raised if the
application response does not conform (minimally) to Rack
expectations. Finally, handling of $request (requests
without “HTTP_VERSION” set in the Rack env) should now be
logged correctly without unnecessary trailing characters.

Hackers: the primary git repository has been moved to
git://git.bogomips.org/clogger.git for now since I’m having
issues with pushing to Rubyforge (seems related to Support
Requests item #26185).

2009/9/2 Eric W. [email protected]:

Clogger is Rack middleware for logging HTTP requests. Â The log format
is customizable so you can specify exactly which fields to log.

Is it possible to make Clogger using Logging class?

Iñaki Baz C. [email protected] wrote:

2009/9/2 Eric W. [email protected]:

Clogger is Rack middleware for logging HTTP requests. The log format
is customizable so you can specify exactly which fields to log.

Is it possible to make Clogger using Logging class?

If you mean Logger, then yes, you can specify anything that responds to
“<<” as your :logger parameter:

use Clogger, :logger => Logger.new("/path/to/log")

El Miércoles, 2 de Septiembre de 2009, Eric W. escribió:

Clogger is Rack middleware for logging HTTP requests. The log format
is customizable so you can specify exactly which fields to log.

Is it possible to make Clogger using Logging class?

If you mean Logger, then yes,

No, I mean Logging:

http://logging.rubyforge.org/

“Logging is a flexible logging library for use in Ruby programs based on
the
design of Java‘s log4j library. It features a hierarchical logging
system,
custom level names, multiple output destinations per log event, custom
formatting, and more.”

you can specify anything that responds to
“<<” as your :logger parameter:

use Clogger, :logger => Logger.new("/path/to/log")

How to set the Logger debug level there?

Thanks a lot.

Iñaki Baz C. [email protected] wrote:

http://logging.rubyforge.org/

“Logging is a flexible logging library for use in Ruby programs based on the
design of Java‘s log4j library. It features a hierarchical logging system,
custom level names, multiple output destinations per log event, custom
formatting, and more.”

It seems to support the “<<” parameter, so I would say yes, it does
work. If you run into any issues, let me know.

you can specify anything that responds to
“<<” as your :logger parameter:

use Clogger, :logger => Logger.new("/path/to/log")

How to set the Logger debug level there?

You can always create the object first and set whatever options you
want:

logger = Logger.new("/path/to/log")
logger.level = Logger::DEBUG
use Clogger, :logger => logger

Of course, the “<<” method Clogger uses internally bypasses level checks
in Logger (same as Rack::CommonLogger)

El Miércoles, 2 de Septiembre de 2009, Iñaki Baz C. escribió:

http://logging.rubyforge.org/

How to set the Logger debug level there?

For example, Logging has “<<” method, but it’s a limited one:

Eric W. [email protected] wrote:

It seems to support the “<<” parameter, so I would say yes, it does

s/parameter/method/, of course

El Miércoles, 2 de Septiembre de 2009, Eric W. escribió:

“<<” as your :logger parameter:
Log the given message without any formatting and without performing any
object over a File object unless you need builtin log rotation[1]
or you want userspace buffering[2].

[1] - which doesn’t work if you’re using multiple processes anyways,
logrotate is a better solution.

[2] - which means you lose data if your application dies unexpectedly

Thanks for the explanation.

Iñaki Baz C. [email protected] wrote:

use Clogger, :logger => Logger.new("/path/to/log")
logger tree if this logger‘s additivity is true.


For request logging, the point of using “<<” is to avoid formatting done
by the Logger. Both Rack::CommonLogger and Clogger already do their own
timestamps and other formatting features (Clogger being highly
configurable)).

So you really don’t get much benefit from using any Logging/Logger
object over a File object unless you need builtin log rotation[1]
or you want userspace buffering[2].

[1] - which doesn’t work if you’re using multiple processes anyways,
logrotate is a better solution.

[2] - which means you lose data if your application dies unexpectedly

El Miércoles, 2 de Septiembre de 2009, Eric W. escribió:

For request logging, the point of using “<<” is to avoid formatting done
by the Logger. Both Rack::CommonLogger and Clogger already do their own
timestamps and other formatting features (Clogger being highly
configurable)).

So you really don’t get much benefit from using any Logging/Logger
object over a File object unless you need builtin log rotation[1]
or you want userspace buffering[2].

What I want to achieve are unified logs (same file and same format).
I’ve already set my Logging instance (for manual logging) and want that
Rack
via Clogger (and also DataMapper) uses the same file and same format.

I expect that I just must configure (or code) the format both Clogger
and
DataMapper use when invoking “<<” method, right?

The fact is I’ve already both Clogger and DataMapper logging via the
Logging
instance (so to the same file), I just need to edit the format to make
it
match,

[1] - which doesn’t work if you’re using multiple processes anyways,
logrotate is a better solution.

Yes, I always use Linux logrotate system rather than the built-in
application
log rotation.

Thanks a lot.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs