Logging Configuration

[Jason]

Can someone help me with my logging configuration? I have read the logging and pyramid_exclog documentation and come up with a configuration that I think should send errors to both a file handler and an SMTP handler, but when an error occurs it is not in the file or emailed -- the error does show up in the stdout (or stderr, they redirect to the same file) though. I am using Paste server (not in daemon mode) with supervisord and Pyramid 1.2. I have absolutely no idea what I have done wrong in this configuration:

[loggers]

keys = root, buildings, sqlalchemy, access_log, exc_logger

[handlers]

keys = console, file, exc_handler

[formatters]

keys = generic

[logger_root]

level = INFO

handlers = file

[logger_buildings]

level = INFO

handlers =

qualname = myapp.buildings

[logger_sqlalchemy]

level = WARN

handlers =

qualname = sqlalchemy.engine

# "level = INFO" logs SQL queries.

# "level = DEBUG" logs SQL queries and results.

# "level = WARN" logs neither.  (Recommended for production systems.)

[logger_access_log]

level = INFO

handlers =

qualname = access_log

[logger_exc_logger]

level = ERROR

handlers = exc_handler

qualname = exc_logger

[handler_console]

class = StreamHandler

args = (sys.stderr,)

level = NOTSET

formatter = generic

[handler_file]

class = logging.handlers.RotatingFileHandler

args = ('/var/log/production.log', 'a', 1048576, 25)

level = INFO

formatter = generic

[handler_exc_handler]

class = handlers.SMTPHandler

args = (('smtp.example.com', 25), 'ja...@example.com', ['ja...@example.com'], '[Error]')

level = ERROR

formatter = generic

[formatter_generic]

format = %(asctime)s %(levelname)-5.5s [%(name)s][%(threadName)s] %(message)s

datefmt = %Y-%m-%d %H:%M:%S

I have also tried setting handlers under logger_exc_logger to "exc_handler, file" in case it wasn't propagating by default, but that did not change anything.

Thanks for the help,

Jason

[Jeff Tchang]

You can try the propagate flag:

[logger_buildings]

level = INFO

handlers =

qualname = myapp.buildings

propagate = 1

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/pylons-discuss/-/2wIBlPOCoucJ.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.

[Arndt Droullier]

Maybe the loggers have to be included in the wsgi pipeline and
configured?

[pipeline:main]
pipeline = ...

[filter:...]

But maybe you already have. This part is missing in your mail.

Arndt.

_______________________________________________________________________

DV Electric
Arndt Droullier
Mail a...@dvelectric.com
Fon 0221/2725782
Fax 0221/2725783
Burgmauer 20, 50667 Köln
http://www.dvelectric.com
_______________________________________________________________________

[Jason]

I did include pyramid_exclog using "pyramid.includes = pyramid_exclog" in the the app section.

[Mattias]

A little warning about the email handler. Remember that SMTPHandler is
a single threaded, blocking, logger. If your logging triggers a email
then all other logging waits until the email is sent. This can quickly
block your entire web app.

We ran into that a couple of days ago. Something caused a logger to
log a critical message which the SMTPHandler picked up and mailed to
us. When that happened the normal info logging was blocked and some of
our timecritical threads started to timeout which in turn triggered
other critical logs. :P

[Sharil Shafie]

Were you able to resolve the logging problem? I encountered the same problem before but with uwsgi, not supervisord. For my case, there was nothing wrong with ini configuration. Thing went ok when I include the logging_config.fileConfig in my uwsgi entry.

 

[Jason]

I think the problem was that pyramid_exclog does its logging in a Tween. When rendering my view an HTTPNotFound exception would be raised and the exception view that handles HTTPNotFound was called. The tween only gets called after the first view and not the second exception handling view which raises a non-http exception.

It seems weird that the Tween gets called between the two views instead of at the end of the request. Maybe logging exceptions is best done in WSGI Middleware.

--Jason

[Jason]

I just looked at the Tween documentation again and realized the exception handling view is implemented as a Tween as well. It could be that I have them ordered incorrectly and the exclog Tween is before the exception view Tween.

--Jason