1

サーバー上で mod_python を実行すると、Python ロギング モジュールの動作が異なるという厄介な問題があります。シェルで、または runserver コマンドまたは mod_wsgi を使用して django で同じコードを実行すると、動作は正しくなります。

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': <logging.RootLogger インスタンス at 0x85f8aac>, 'handlers': []、「レベル」: 0、「無効」: 0、「マネージャー」: <0x85f8aec の logging.Manager インスタンス>、「伝播」: 1、「フィルター」: []}]

2009-05-28 10:36:43,740,DEBUG,error_middleware.py:32,[logger.parent={'name': 'root', 'parent': None, 'handlers': [<logging.StreamHandler インスタンスで0x8ec612c>、<logging.handlers.RotatingFileHandler インスタンス 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

2 つ目の問題は、__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)

ログにカスタム ハンドラが表示されません。

誰かが問題の場所を知っている場合は、お知らせください。追加情報を求めることを躊躇しないでください。それは確かに問題を解決するのに役立ちます。

4

3 に答える 3

5

ログインを設定しない方が良いかもしれませんsettings.py。

ルートでログを構成しますurls.py。これはうまくいくようです。私は Django のソースを十分に読んでいないので、なぜそれが優れているのかを正確に知ることはできませんが、私たちにとってはうまく機能しています。ここにもカスタム ハンドラを追加します。

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

于 2009-05-28T10:04:46.057 に答える
0

関連するすべての情報を投稿していないようです。たとえば、ロギング構成ファイルはどこにありますか?

あなたはこう言います：

シェル、または runserver コマンドまたは mod_wsgi を使用して django で同じコードを実行すると、動作は正しくなります。

あなたが示したログ出力がこれらの環境のいずれかからのものなのか、それとも mod_python の実行からのものなのかを明確にしません。それは間違っているようには見えません - あなたのコードでは、ロガーの「サイトエラー」ではなく、ルートにハンドラーを追加しました。また、ロガーではなくハンドラーにレベルを設定します。そのため、ログ出力で「サイト エラー」ロガーに設定されたレベルが表示されるとは思わないでしょうか? レベルはロガーとハンドラーの両方で設定でき、同じ方法でイベントを除外しますが、同じではありません。

カスタム ハンドラーに関する問題は、構成に関するログのドキュメントを見れば簡単に説明できます。

http://docs.python.org/library/logging.html (「クラス エントリが示す」を検索)

これは、構成ファイルに記述されているすべてのハンドラー クラスが、ロギング パッケージの名前空間で eval() されることを説明しています。そのため、logging.custhandlers をカスタム ハンドラ モジュールにバインドし、構成ファイルで「custhandlers.MyCustomClass」を指定すると、eval() は期待どおりの結果を生成します。あなたは同じようにやったかもしれません

logging.sitemonitoring = サイト監視

ハンドラークラスを次のように指定しました

sitemonitoring.db_log_handler.DBLogHandler

これも同様に機能します (db_log_handler サブパッケージが既にインポートされている限り)。

ところで、settings.py でログの構成に問題が発生することがある理由は、Django のインポート マジックが循環インポートの問題を引き起こしているためです。私は通常、settings.py でログを構成します。Django の特定の部分をインポートする必要がない限り (django.db など)、正常に動作します。 settings.py に django.db.x をインポートします)。

于 2009-06-07T16:26:25.217 に答える