Disable logging of all hits

[Landon]

Hey all,

I'm looking for a smarter way than editing the source of of the
framework to disable the logging of every hit and file served from /
static (for example).

Is there an easier way to just disable that verbosity?

[David P. Novakovic]

I think turning off debug does exactly that.

D

[Landon]

You can retain debug mode and just set 'options.logging = "none" ' in
your Application. Or to whatever level is available. (https://
github.com/facebook/tornado/blob/master/tornado/options.py bottom of
the file.)

Docstrings FTW!

On Jan 20, 5:07 pm, "David P. Novakovic" <davidnovako...@gmail.com>
wrote:

[Ben Darnell]

Be careful, that only accidentally does what you're looking for.  --logging=none tells tornado not to touch your logging configuration.  The python logging module defaults to only logging warnings and above, while tornado defaults to info.  You could have a similar effect with --logging=warning to get tornado's log formatting but not log any info messages (but note that there may be more than just http requests logged at the info level).

The other way to disable this per-request logging without losing all other info messages along with it is to subclass RequestHandler and override _log().  For static files, this means also using a custom subclass of StaticFileHandler and binding it to /static/ manually instead of using the one tornado can create for you automatically.

I don't think setting debug mode has any effect on the logging configuration (maybe you're thinking of --logging=debug?), but I might be forgetting something.

-Ben

[Peter Bengtsson]

I did that. Thanks to your advice Ben.

It's working great for me because I can use `logging.info('New user registered')` type statements without them being overcrowded by basic requests.

However, I'm not convinced about overriding a private method for such a basic preference. It would be better if this was configurable. Would you like me to fork a pull request and share a possible solution?

[Ben Darnell]

I just checked in a change to move all the logging from the RequestHandler to the Application (configurable via either subclassing or settings).

-Ben

[Gavin M. Roy]

Should this be changed to call the new function?

https://github.com/facebook/tornado/blob/master/tornado/web.py#L592

[Ben Darnell]

No, this is deliberate.  I've said before that applications can treat the _log() method as "protected" instead of "private" and consider it safe to override, so I left the old method in place so such an override will continue to work.

-Ben

[Gavin M. Roy]

So by default the path is RequestHandler._log to -> Application.log_request and if you want to overwrite the logging behavior (beyond modifying logging module settings) you can:

Redefine _log (By extending RequestHandler)

Redefine log_request (By extending Application or passing in a log_request function in the settings)

And the only person that invokes Application.log_request is RequestHandler._log, correct?

[Ben Darnell]

Right.

-Ben

[Gavin M. Roy]

As a suggestion since you're still thinking in this space right now, would it not make sense from a bigger picture perspective to push logging down to HTTPRequest or HTTPServer?

It seems to me that the context of the log by default is a HTTP Request log, not an application or request handler event log.

Not trying to bike-shed.

Gavin

[Ben Darnell]

That's true, but it would take a greater refactoring to make the HTTPServer accessible inside the application.  There are also times when you don't have an HTTPServer (i.e. WSGIApplication), but we don't log in wsgi mode anyway (which actually strengthens the conceptual case for doing the logging in HTTPServer).

-Ben

[Gavin M. Roy]

On Fri, Jan 21, 2011 at 5:04 PM, Ben Darnell <b...@bendarnell.com> wrote:

That's true, but it would take a greater refactoring to make the HTTPServer accessible inside the application.  There are also times when you don't have an HTTPServer (i.e. WSGIApplication), but we don't log in wsgi mode anyway (which actually strengthens the conceptual case for doing the logging in HTTPServer).

Could a refactor look like passing logging_enabled=True/False to the HTTPServer constructor?

Disabling logging at the HTTPServer shouldn't (and wouldn't) preclude the use of logging.info/error/debug in RequestHandler. 

Is there a use case for disabling a request log that falls outside of doing so on creation/start of the server?

I'd be happy to make a patch for this behavior.

If we wanted to make it even more full featured, RequestHandler._log would use loggging.info, prepending the log line with the Request Handler class and info.

Regards,

Gavin

[Ben Darnell]

It's more complicated than just enabling/disabling logging; you also need to be able to plug in custom logging (to change the content and/or destination of the log).  In general, I'm reluctant to put things on the HTTPServer side of the fence because the interface between tornado.httpserver and tornado.web is so limited (and tends to lead to piling more unrelated stuff into HTTPRequest).  

-Ben