mod_pythonを使用したときのPythonロギングモジュールの動作が異なります

Question

私たちはサーバー上でmod_pythonを使用しているときに、Pythonロギングモジュールが異なる動作をしているという厄介な問題があります。シェル、またはジャンゴでの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'： 'サイトエラー'、 '親' ：0、 '無効'：0、 'manager'：< logging.Managerインスタンス0x85f8aec >、 'propagate'：1、 'filters'：[]}]

2009-05-28 DEBUG、error_middleware.py：32、[logger.parent = {'name'： 'ルート'、 '親'：なし 'ハンドラ'： [< 10、 '無効'： 0x8ec612c >、0x8ec616c >で < logging.handlers.RotatingFileHandlerインスタンス]、 'レベル' でインスタンス.StreamHandler 0、 '伝播'：1、 'フィルタ'：[]}]

このように、子ロガーの「サイトエラー」に対してハンドラまたはレベルは設定されていません。

ロギング設定が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 

は、第二の問題は、我々はまた、そのフォルダ内のerror_middleware.pyとして存在__init__.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) 

カスタムハンドラはログに記録されません！

誰かが問題の原因を知っている場合は、お知らせください。別の情報を求めていることをためらってはいけません。それは確かに問題を解決するのに役立ちます。

Answer 1

settings.pyでログを設定しないと良い場合があります。

ログは、ルートurls.pyに設定します。これはうまくいくようです。私はDjangoのソースを十分に読んでいないので、正確にはそれが良いのですが、うまく動いています。ここでカスタムハンドラを追加します。

また、mod_wsgiをよくご覧ください。 mod_pythonよりもはるかに優れているようです。

Answer 2

問題はmod_wsgiを使用して解決されません。

完全な構成を1つのファイルに入れることで、この問題を解決できました。ファイルとコードの設定を混在させると、Apache（mod_wsgiまたはmod_pythonを使用しているかどうか）に問題が発生するようです。ファイル構成とカスタムログハンドラを使用するには

、私は次の操作を実行する必要がありました：

import logging 
import logging.config 
logging.custhandlers = sitemonitoring.db_log_handler 
logging.config.fileConfig(settings.MONITORING_FILE_CONFIG) 

設定から。py sitemonitoring.db_log_handlerをインポートできないので、このコードをルートurls.pyに配置する必要があります。設定ファイルで

、私は次の文

[handler_db] 
class=custhandlers.DBLogHandler() 
level=ERROR 
args=(,) 

PSでDBLogHandlerを参照してください。custhandler「属性は」動的に作成され、別の名前を持つことができることに注意してください。これは、動的言語を使用する利点です。

Answer 3

関連するすべての情報を投稿しているようではありません。たとえば、ロギング設定ファイルはどこですか？

あなたがいることを言う：「あなたはドン シェルで、またはジャンゴでのrunserver コマンドを使用して、またはのmod_wsgiと同じコードを実行するとき

、行動 が正しい

です表示されたロギング出力がこれらの環境のいずれかであるかどうか、またはそれがmod_python実行のものかどうかを確認してください。それは間違っていません - あなたのコードで、ルートにハンドラを追加しました。ロガーの 'site-errors'には追加しません。また、ロガーではなくハンドラーのレベルを設定するので、ロギング出力の 'site-errors'ロガーのレベルセットがないと思わないでしょうか。レベルは、ロガーとハンドラーの両方で設定できますが、同じ方法でイベントを除外しますが、レベルは同じではありません。

あなたが設定のログのドキュメントを見れば容易に説明されるカスタムハンドラに関する問題、これは、任意のハンドラクラスはで説明していることを説明し（「クラスエントリが示す」で検索）

を

http://docs.python.org/library/logging.htmlを見ます設定ファイルはロギングパッケージの名前空間にeval（）されます。したがって、logging.custhandlersをカスタムハンドラモジュールにバインドし、configファイルに "custhandlers.MyCustomClass"と記述すると、eval（）は期待した結果を生成します。あなただけのようにも限り（

をsitemonitoring =

logging.sitemonitoringを行われ、同じようにうまく機能することになる

sitemonitoring.db_log_handler.DBLogHandler

としてハンドラクラスを指定している可能性がdb_log_handlerサブパッケージはすでにインポートされています）。

ところで人々がsettings.pyのログインを設定する際に問題を起こすことがある理由は、Djangoのインポートマジックが循環インポートの問題を引き起こすためです。私は一般的にsettings.pyのログインを設定して、Djangoの特定のビットをインポートしない限り、正常に動作します（例えば、django.dbの場合 - アプリケーションのインポートロジックがdjango.dbになっているので、 settings.pyのdjango.db.xをインポートしてください）。