使用 mod_python 时 python 日志记录模块的不同行为
我们遇到了一个棘手的问题，我们发现 python 日志记录模块在我们的服务器上使用 mod_python 运行时表现不同。 当在 shell 中或在 django 中使用 runserver 命令或 mod_wsgi 执行相同的代码时，行为是正确的：
import logging
logger = logging.getLogger('site-errors')
logging.debug('logger=%s' % (logger.__dict__))
logging.debug('logger.parent=%s' % (logger.parent.__dict__))
logger.error('some message that is not logged.')
然后我们记录以下日志：
2009-05-28 10:36:43,740,DEBUG,error_middleware.py:31,[logger={'name': 'site-errors', 'parent':
, 'handlers': [], 'level': 0, 'disabled': 0, 'manager': , 'propagate': 1, 'filters': []}] 2009-05-28 10:36:43,740,调试,error_middleware.py:32,[logger.parent={'name': '根'，'父级'：无，'处理程序'： [
, 实例位于 0x8ec616c>]，“级别”：10， “禁用”：0，“传播”：1， “过滤器”：[]}]
正如我们所看到的，没有为子记录器 'site-errors' 设置处理程序或级别。
日志记录配置在 settings.py 中完成：
MONITOR_LOGGING_CONFIG = ROOT + 'error_monitor_logging.conf'
import logging
import logging.config
logging.config.fileConfig(MONITOR_LOGGING_CONFIG)
if CONFIG == CONFIG_DEV:
DB_LOGLEVEL = logging.INFO
else:
DB_LOGLEVEL = logging.WARNING
第二个问题是我们还在 __init__.py 中添加了一个自定义处理程序，该处理程序位于文件夹中作为 error_middleware.py：
import logging
from django.conf import settings
from db_log_handler import DBLogHandler
handler = DBLogHandler()
handler.setLevel(settings.DB_LOGLEVEL)
logging.root.addHandler(handler)
自定义处理程序在日志记录中看不到！
如果有人知道问题出在哪里，请告诉我们！ 请随时询问更多信息。 这肯定有助于解决问题。
We have a nasty problem where we see that the python logging module is behaving differently when running with mod_python on our servers. When executing the same code in the shell, or in django with the runserver command or with mod_wsgi, the behavior is correct:
import logging
logger = logging.getLogger('site-errors')
logging.debug('logger=%s' % (logger.__dict__))
logging.debug('logger.parent=%s' % (logger.parent.__dict__))
logger.error('some message that is not logged.')
We then the following logging:
2009-05-28 10:36:43,740,DEBUG,error_middleware.py:31,[logger={'name': 'site-errors', 'parent': <logging.RootLogger instance at 0x85f8aac>, 'handlers': [], 'level': 0, 'disabled': 0, 'manager': <logging.Manager instance at 0x85f8aec>, 'propagate': 1, 'filters': []}]
2009-05-28 10:36:43,740,DEBUG,error_middleware.py:32,[logger.parent={'name':
'root', 'parent': None, 'handlers':
[<logging.StreamHandler instance at
0x8ec612c>,
<logging.handlers.RotatingFileHandler
instance at 0x8ec616c>], 'level': 10,
'disabled': 0, 'propagate': 1,
'filters': []}]
As one can see, no handlers or level is set for the child logger 'site-errors'.
The logging configuration is done in the settings.py:
MONITOR_LOGGING_CONFIG = ROOT + 'error_monitor_logging.conf'
import logging
import logging.config
logging.config.fileConfig(MONITOR_LOGGING_CONFIG)
if CONFIG == CONFIG_DEV:
DB_LOGLEVEL = logging.INFO
else:
DB_LOGLEVEL = logging.WARNING
The second problem is that we also add a custom handler in the __init__.py that resides that in the folder as error_middleware.py:
import logging
from django.conf import settings
from db_log_handler import DBLogHandler
handler = DBLogHandler()
handler.setLevel(settings.DB_LOGLEVEL)
logging.root.addHandler(handler)
The custom handler cannot be seen in the logging!
If someone has idea where the problem lies, please let us know! Don't hesistate to ask for additonal information. That will certainly help to solve the problem.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您不在
settings.py中配置日志记录，可能会更好。我们在根
urls.py中配置您的日志记录。 这似乎效果更好。 我还没有阅读足够多的 Django 源代码，不知道为什么它更好，但它对我们来说效果很好。 我也会在这里添加自定义处理程序。另外，请仔细查看 mod_wsgi。 它的表现似乎比 mod_python 好得多。
It may be better if you do not configure logging in
settings.py.We configure your logging in our root
urls.py. This seems to work out better. I haven't read enough Django source to know why, precisely, it's better, but it's working out well for us. I would add custom handlers here, also.Also, look closely at mod_wsgi. It seems to behave much better than mod_python.
使用mod_wsgi并没有解决这个问题。
我可以通过将完整的配置放入一个文件来解决该问题。 混合文件和代码配置似乎会给 apache 带来问题（无论使用 mod_wsgi 还是 mod_python）。
要使用带有文件配置的自定义日志记录处理程序，我必须执行以下操作：
从 settings.py 中，我无法导入
sitemonitoring.db_log_handler，因此我必须将此代码放在根中urls.py。在配置文件中，我使用以下语句引用
DBLogHandlerPS：请注意，
custhandler“属性”是动态创建的，可以有其他名称。 这是使用动态语言的优点。The problem is not solved by using mod_wsgi.
I could solve the problem by placing the complete configuration into one file. Mixing file and code configuration seems to create problems with apache (whether using mod_wsgi or mod_python).
To use a custom logging handler with file configuration, I had to do the following:
From the settings.py I cannot import the
sitemonitoring.db_log_handler, so I have to place this code in the rooturls.py.In the config file, I refer to the
DBLogHandlerwith the following statementPS: Note that the
custhandler'attribute' is created dynamically and can have another name. This is an advantage of using a dynamic language.您似乎没有发布所有相关信息 - 例如，您的日志记录配置文件在哪里？
你说：
您不清楚您显示的日志输出是否来自这些环境之一，或者是否来自 mod_python 运行。 它看起来没有错误 - 在您的代码中，您将处理程序添加到根目录，而不是记录“站点错误”。 您还在处理程序上设置了一个级别，而不是记录器 - 所以您不会期望在日志输出中看到为“站点错误”记录器设置的级别，嗯？ 级别可以在记录器和处理程序上设置，尽管它们以相同的方式过滤事件，但它们并不相同。
如果您查看配置的日志记录文档，则有关自定义处理程序的问题很容易解释，请参阅
http:// /docs.python.org/library/logging.html（搜索“类条目指示”）
这解释了配置文件中描述的任何处理程序类都在日志记录包命名空间中进行了 eval() 处理。 因此，通过将logging.custhandlers绑定到自定义处理程序模块，然后在配置文件中声明“custhandlers.MyCustomClass”，eval()会产生预期的结果。 您也可以完成
logging.sitemonitoring = sitemonitoring
并将处理程序类指定为
sitemonitoring.db_log_handler.DBLogHandler
，它也可以正常工作（只要已经导入了db_log_handler子包）。
顺便说一句，人们有时在 settings.py 中配置日志记录时遇到问题的原因是 Django 的导入魔法导致循环导入问题。 我通常在 settings.py 中配置日志记录，它工作得很好，除非你想导入 Django 的某些部分（例如在 django.db 中 - 因为应用程序导入逻辑在 django.db 中，如果你尝试在settings.py中导入django.db.x）。
You don't appear to have posted all the relevant information - for example, where is your logging configuration file?
You say that:
You don't make clear whether the logging output you showed is from one of these environments, or whether it's from a mod_python run. It doesn't look wrong - in your code you added handlers to the root, not to logger 'site-errors'. You also set a level on the handler, not the logger - so you wouldn't expect to see a level set for the 'site-errors' logger in the logging output, neh? Levels can be set on both loggers and handlers and they are not the same, though they filter out events in the same way.
The issue about custom handlers is easily explained if you look at the logging documentation for configuration, see
http://docs.python.org/library/logging.html (search for "the class entry indicates")
This explains that any handler class described in the configuration file is eval()'d in the logging packages namespace. So, by binding logging.custhandlers to your custom handlers module and then stating "custhandlers.MyCustomClass" in the config file, the eval() produces the expected result. You could just as well have done
logging.sitemonitoring = sitemonitoring
and specified the handler class as
sitemonitoring.db_log_handler.DBLogHandler
which would work just as well (as long as the db_log_handler subpackage has been imported already).
BTW the reason why people sometimes have problems configuring logging in settings.py is due to Django's import magic causing circular import problems. I generally configure logging in settings.py and it works fine unless you want to import certain bits of Django (e.g. in django.db - because the app import logic is in django.db, you can run into circular import issues if you try to import django.db.x in settings.py).