18.3. FILTERING LOG MESSAGES
16:20:20,440 DEBUG [myapp.views] Returning: Hello World! (content-type: text/plain)
18.3 Filtering log messages
Often there’s too much log output to sift through, such as when switching the root logger’s level to DEBUG.
An example: you’re diagnosing database connection issues in your application and only want to see SQLAlchemy’s DEBUG messages in relation to database connection pooling. You can leave the root logger’s level at the less verbose INFO level and set that particular SQLAlchemy logger to DEBUG on its own, apart from the root logger:
[logger_sqlalchemy.pool] level = DEBUG
handlers =
qualname = sqlalchemy.pool
then add it to the list of loggers:
[loggers]
keys = root, myapp, sqlalchemy.pool
No handlers need to be configured for this logger as by default non root loggers will propagate their log records up to their parent logger’s handlers. The root logger is the top level parent of all loggers.
This technique is used in the default development.ini. The root logger’s level is set to INFO, whereas the application’s log level is set to DEBUG:
# Begin logging configuration
[loggers]
keys = root, myapp
[logger_myapp] level = DEBUG handlers =
qualname = helloworld
201
18. LOGGING
All of the child loggers of the myapp logger will inherit the DEBUG level unless they’re explicitly set differently. Meaning the myapp.views, myapp.models (and all your app’s modules’) loggers by default have an effective level of DEBUG too.
For more advanced filtering, the logging module provides a Filter object; however it cannot be used directly from the configuration file.
18.4 Advanced Configuration
To capture log output to a separate file, use a FileHandler (or a RotatingFileHandler):
[handler_filelog] class = FileHandler
args = (’%(here)s/myapp.log’,’a’) level = INFO
formatter = generic
Before it’s recognized, it needs to be added to the list of handlers:
[handlers]
keys = console, myapp, filelog
and finally utilized by a logger.
[logger_root] level = INFO
handlers = console, filelog
These final 3 lines of configuration directs all of the root logger’s output to the myapp.log as well as the console.
18.5 Logging Exceptions
To log (or email) exceptions generated by your Pyramid application, use the pyramid_exclog package. Details about its configuration are in its documentation.
202
18.6.REQUEST LOGGING WITH PASTE’S TRANSLOGGER
18.6Request Logging with Paste’s TransLogger
Paste provides the TransLogger middleware for logging requests using the Apache Combined Log Format. TransLogger combined with a FileHandler can be used to create an access.log file similar to Apache’s.
Like any standard middleware with a Paste entry point, TransLogger can be configured to wrap your application using .ini file syntax. First, rename your Pyramid .ini file’s [app:main] section to [app:mypyramidapp], then add a [filter:translogger] section, then use a
[pipeline:main] section file to form a WSGI pipeline with both the translogger and your application in it. For instance, change from this:
[app:main]
use = egg:MyProject
To this:
[app:mypyramidapp] use = egg:MyProject
[filter:translogger]
use = egg:Paste#translogger setup_console_handler = False
[pipeline:main] pipeline = translogger
mypyramidapp
Using PasteDeploy this way to form and serve a pipeline is equivalent to wrapping your app in a TransLogger instance via the bottom the main function of your project’s __init__ file:
...
app = config.make_wsgi_app()
from paste.translogger import TransLogger
app = TransLogger(app, setup_console_handler=False) return app
TransLogger will automatically setup a logging handler to the console when called with no arguments, so it ‘just works’ in environments that don’t configure logging. Since we’ve configured our own logging handlers, we need to disable that option via setup_console_handler = False.
With the filter in place, TransLogger’s logger (named the ‘wsgi’ logger) will propagate its log messages to the parent logger (the root logger), sending its output to the console when we request a page:
203
18. LOGGING
00:50:53,694 INFO [myapp.views] Returning: Hello World! (content-type: text/plain)
00:50:53,695 INFO [wsgi] 192.168.1.111 - - [11/Aug/2011:20:09:33 -0700] "GET /hello HTTP/1.1" 404 - "-"
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6"
To direct TransLogger to an access.log FileHandler, we need to add that FileHandler to the wsgi logger’s list of handlers:
# Begin logging configuration
[loggers]
keys = root, myapp, wsgi
[logger_wsgi] level = INFO
handlers = handler_accesslog qualname = wsgi
propagate = 0
[handler_accesslog] class = FileHandler
args = (’%(here)s/access.log’,’a’) level = INFO
formatter = generic
As mentioned above, non-root loggers by default propagate their log records to the root logger’s handlers (currently the console handler). Setting propagate to 0 (false) here disables this; so the wsgi logger directs its records only to the accesslog handler.
Finally, there’s no need to use the generic formatter with TransLogger as TransLogger itself provides all the information we need. We’ll use a formatter that passes-through the log messages as is:
[formatters]
keys = generic, accesslog
[formatter_accesslog] format = %(message)s
Then wire this new accesslog formatter into the FileHandler:
204
18.6. REQUEST LOGGING WITH PASTE’S TRANSLOGGER
[handler_accesslog] class = FileHandler
args = (’%(here)s/access.log’,’a’) level = INFO
formatter = accesslog
205
18. LOGGING
206