18:djangoログシステム
21443 ワード
原文のリンク:http://www.cnblogs.com/qwj-sysu/p/4218536.html
djangoはpython内に建設されたloggingモジュールを使って自分のシステムログを作成します.もしこのモジュールを詳しく知りたいなら、自分でpythonの説明文書を見に行ってください.ここではdjango中のログシステムを紹介します.
ログの構成は4つの部分を含みます.レコーダ、プロセッサ、フィルタ、フォーマットなどを説明します.
レコーダ
レコーダはログシステムのエンティティであり、各レコーダは、メッセージをプロセスに書き込むことができる名前が付けられた「バケット」である.
各レコーダにはログレベルがあります.各レベルは、レコーダが処理しようとする情報の重大性を記述しています.pythonは、以下の5つのレベルを定義しています.
デバッグ目的の低レベルシステム情報 info:一般的なシステム情報 warning:すでに発生した小さい問題を説明します. error:すでに発生した主要問題を説明する critical:すでに発生した深刻な問題を説明する 各レコーダに書き込まれた情報はログ記録となり、各ログ記録にはその記録の重要性を示すログレベルがあり、各ログ情報にもいくつかの有用なメタ情報が記録されたイベント、例えばスタック追跡やエラーコードなどを含む.
一つの情報がレコーダに送信されると、メッセージの記録レベルはレコーダのレベルと比較され、現在のレベルを超えても該当する場合はプロセッサに送信されます.そうでなければ無視されます.
プロセッサ
プロセッサは、ログレコーダにおける対応するエンティティメッセージの発生を決定するエンジンであり、スクリーンに出力するか、またはファイルに出力するか、またはネットワークsocketのような具体的なログ挙動を説明する.
レコーダと同様に、対応するレベルに達していないメッセージは無視されます.
一つのレコーダは複数のプロセッサを有してもよく、一つのプロセッサは異なるログレベルを有してもよいので、メッセージの重要性に応じて異なるヒントを提供することができる.
フィルタ
フィルタは、追加の制御を提供するために使用されています.どのログ記録がプロセッサに送信されて処理されますか?
デフォルトでは、ログメッセージが対応するレベル要件を満たすと、対応するプロセッサに送信されますが、フィルタをインストールすることによって、ログ記録中に追加の内容を設定することができます.例えば、フィルタをインストールして、ソースがerrorレベルのメッセージしか送信されないようにしてもいいです.フィルタを使用して修正する前に送信されるメッセージ、例えば、ある条件に合致するerrorレベルのメッセージをwarningレベルに格下げするフィルタを書いてもいいです.
フィルタはプロセッサとレコーダに使用でき、複数のフィルタはカスケード化して使用できます.
書式設定器
ログ出力のフォーマットを制御して、フォーマットはpythonの文字列のコントロールフォーマットを使います.
ログを使う
レコーダ、プロセッサ、フィルタ、フォーマットを設定すると、ログ機能をあなたのコードから呼び出す必要があります.以下は簡単な例です.
あなたのレコーダの名前を付けてください.
loging.get Logger()の呼び出しでレコーダのエンティティが得られ、レコーダエンティティは名前で判別される.
上の例のように、__uを使うのが一般的です.name_,レコーダを含むpythonモジュールの名前は、各モジュールに基づく記録を可能にする.
または、ポイント番号で接続された名前であってもいいです.これは、レコーダのレベルを意味します.ポイント番号の前のものは、ポイント番号の後の親モジュール、例えば、
このような方法も重要です.階層を通して、サブレベルのメッセージは自分の父レベルにメッセージを送ることができます.もしあなたがメッセージをあなたの父レベルに送りたくないなら、送信スイッチを切ってください.(以下、紹介します)
ログの呼び出し
ログの5つのレベルに対応して、ログの呼び出しには5つの対応方法があります. logger.critical() logger.error() logger.warning() logger.info() logger.debug() もう2つの利用可能なログ方法があります. logger.logs():具体的なレベルのログメッセージを手動で送信する logger.exception():異常スタックフレームの内容をカプセル化したerrorレベルのログメッセージ を作成する.
ログシステムの設定
コードでログを呼び出す前提は、ログシステムのレコーダ、プロセッサ、フィルタ、フォーマットがすでに設定されているので、複雑な例を通して詳しく説明しましょう.
この例を見てから、日誌システムの構成については大体分かりましたよね.
循環導入問題
プロセッサをカスタマイズしてセットアップしてください.もしこれがクラス実現ファイルにsettingsモジュールを導入した場合、循環導入の問題が発生します.settings.pyプロファイルだけに配置することをお勧めします.
カスタマイズログの設定とログの設定を無効にします.
LOGGINGを使うCONFIG属性のカスタマイズとログの設定を無効にし、LOGGING_CONFIG=None無効
django日誌拡張
djangoは3つの自分のレコーダを提供します.
django
djangoレコーダは、すべてのメッセージをキャプチャするレコーダであり、メッセージなしに直接djangoレコーダに送信される.
django.request
5 XXはerrorメッセージを引き起こします.4 XXはwarningメッセージを誘発します.このレコーダには追加の文脈があります. status_code:HTTP応答ですか? request:このメッセージを生成するrequestオブジェクト django.db.backens
すべての要求によって実行されるsql文は、一つのdebugのメッセージを記録します.各レコーダには、追加のコンテキストが添付されています. duration:sql文の実行時間 sql:運転のsql文 params:sql文で起動されるパラメータ ウェブサイトの運行の表現の原因があって、settings.DEBUG=Trueの時だけ、このプロセッサは有効になります.そうでないと設定しても無効になります.
pythonモジュールの他に、djangoはプロセッサをカスタマイズしました.
class AdminEmail Handler(include-=False)
このプロセッサはメッセージを受信するごとにサイト管理者に送っています.ログ情報にはrequest属性が含まれている場合、request全体の詳細情報もEmailに含まれてサイト管理者に送られます.ログ情報にスタック追跡情報が含まれている場合、スタック追跡情報も送信されます.
include_)プロパティコントロールはDEBUGが本物の場合、トレース情報を送るかどうか、これらは敏感なシステムですので、もし誰かに遮断されたら、危険が発生する可能性がありますので、注意してください.この属性を設定する例は以下の通りです.
pythonが持っているものを除いて、djangoは2つのフィルターを提供しています.
class CallBackFilter(calback)
このフィルタは一つのコールバック関数(この関数はパラメータを受け取り、記録された情報)を受けています.各記録はフィルタを通過すると、このコールバック関数を呼び出します.コールバック関数がFalseに戻ると、この記録は処理されません.以下は一例です.
class Require DebugFalse
このフィルタはsettings.DEBUGがFalseである場合にのみ有効です.デフォルトは有効です.settings.DEBUG=Falseの場合にのみ、AdminEmail Handlerは有効です.
転載先:https://www.cnblogs.com/qwj-sysu/p/4218536.html
djangoはpython内に建設されたloggingモジュールを使って自分のシステムログを作成します.もしこのモジュールを詳しく知りたいなら、自分でpythonの説明文書を見に行ってください.ここではdjango中のログシステムを紹介します.
ログの構成は4つの部分を含みます.レコーダ、プロセッサ、フィルタ、フォーマットなどを説明します.
レコーダ
レコーダはログシステムのエンティティであり、各レコーダは、メッセージをプロセスに書き込むことができる名前が付けられた「バケット」である.
各レコーダにはログレベルがあります.各レベルは、レコーダが処理しようとする情報の重大性を記述しています.pythonは、以下の5つのレベルを定義しています.
デバッグ目的の低レベルシステム情報
一つの情報がレコーダに送信されると、メッセージの記録レベルはレコーダのレベルと比較され、現在のレベルを超えても該当する場合はプロセッサに送信されます.そうでなければ無視されます.
プロセッサ
プロセッサは、ログレコーダにおける対応するエンティティメッセージの発生を決定するエンジンであり、スクリーンに出力するか、またはファイルに出力するか、またはネットワークsocketのような具体的なログ挙動を説明する.
レコーダと同様に、対応するレベルに達していないメッセージは無視されます.
一つのレコーダは複数のプロセッサを有してもよく、一つのプロセッサは異なるログレベルを有してもよいので、メッセージの重要性に応じて異なるヒントを提供することができる.
フィルタ
フィルタは、追加の制御を提供するために使用されています.どのログ記録がプロセッサに送信されて処理されますか?
デフォルトでは、ログメッセージが対応するレベル要件を満たすと、対応するプロセッサに送信されますが、フィルタをインストールすることによって、ログ記録中に追加の内容を設定することができます.例えば、フィルタをインストールして、ソースがerrorレベルのメッセージしか送信されないようにしてもいいです.フィルタを使用して修正する前に送信されるメッセージ、例えば、ある条件に合致するerrorレベルのメッセージをwarningレベルに格下げするフィルタを書いてもいいです.
フィルタはプロセッサとレコーダに使用でき、複数のフィルタはカスケード化して使用できます.
書式設定器
ログ出力のフォーマットを制御して、フォーマットはpythonの文字列のコントロールフォーマットを使います.
ログを使う
レコーダ、プロセッサ、フィルタ、フォーマットを設定すると、ログ機能をあなたのコードから呼び出す必要があります.以下は簡単な例です.
# import the logging library
import logging
# Get an instance of a logger
logger = logging.getLogger(__name__)
def my_view(request, arg1, arg):
...
if bad_mojo:
# Log an error message
logger.error('Something went wrong!')
あなたのレコーダの名前を付けてください.
loging.get Logger()の呼び出しでレコーダのエンティティが得られ、レコーダエンティティは名前で判別される.
上の例のように、__uを使うのが一般的です.name_,レコーダを含むpythonモジュールの名前は、各モジュールに基づく記録を可能にする.
または、ポイント番号で接続された名前であってもいいです.これは、レコーダのレベルを意味します.ポイント番号の前のものは、ポイント番号の後の親モジュール、例えば、
# Get an instance of a specific named logger
logger = logging.getLogger('project.interesting.stuff')
このような方法も重要です.階層を通して、サブレベルのメッセージは自分の父レベルにメッセージを送ることができます.もしあなたがメッセージをあなたの父レベルに送りたくないなら、送信スイッチを切ってください.(以下、紹介します)
ログの呼び出し
ログの5つのレベルに対応して、ログの呼び出しには5つの対応方法があります.
ログシステムの設定
コードでログを呼び出す前提は、ログシステムのレコーダ、プロセッサ、フィルタ、フォーマットがすでに設定されているので、複雑な例を通して詳しく説明しましょう.
LOGGING = {
'version': 1,# dictConnfig , ,
'disable_existing_loggers': True,#
'formatters': {#
'verbose': {#
'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'
},
'simple': {#
'format': '%(levelname)s %(message)s'
},
},
'filters': {#
'special': {# project.logging.SpecialFilter, special,
'()': 'project.logging.SpecialFilter',
'foo': 'bar',# , foo, bar
}
},
'handlers': {# ,
'null': {#Null , ( )debug /dev/null
'level':'DEBUG',
'class':'django.utils.log.NullHandler',
},
'console':{# , ( )debug stderr, simple
'level':'DEBUG',
'class':'logging.StreamHandler',
'formatter': 'simple'
},
'mail_admins': {#AdminEmail , ( ) error , special
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler',
'filters': ['special']
}
},
'loggers': {#
'django': {# null , ( )info null ,
'handlers':['null'],
'propagate': True,
'level':'INFO',
},
'django.request': {# ( )error mail_admins ,
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': False,
},
'myproject.custom': {# ( )info console mail_admins , special
'handlers': ['console', 'mail_admins'],
'level': 'INFO',
'filters': ['special']
}
}
}
この例を見てから、日誌システムの構成については大体分かりましたよね.
循環導入問題
プロセッサをカスタマイズしてセットアップしてください.もしこれがクラス実現ファイルにsettingsモジュールを導入した場合、循環導入の問題が発生します.settings.pyプロファイルだけに配置することをお勧めします.
カスタマイズログの設定とログの設定を無効にします.
LOGGINGを使うCONFIG属性のカスタマイズとログの設定を無効にし、LOGGING_CONFIG=None無効
django日誌拡張
djangoは3つの自分のレコーダを提供します.
django
djangoレコーダは、すべてのメッセージをキャプチャするレコーダであり、メッセージなしに直接djangoレコーダに送信される.
django.request
5 XXはerrorメッセージを引き起こします.4 XXはwarningメッセージを誘発します.このレコーダには追加の文脈があります.
すべての要求によって実行されるsql文は、一つのdebugのメッセージを記録します.各レコーダには、追加のコンテキストが添付されています.
pythonモジュールの他に、djangoはプロセッサをカスタマイズしました.
class AdminEmail Handler(include-=False)
このプロセッサはメッセージを受信するごとにサイト管理者に送っています.ログ情報にはrequest属性が含まれている場合、request全体の詳細情報もEmailに含まれてサイト管理者に送られます.ログ情報にスタック追跡情報が含まれている場合、スタック追跡情報も送信されます.
include_)プロパティコントロールはDEBUGが本物の場合、トレース情報を送るかどうか、これらは敏感なシステムですので、もし誰かに遮断されたら、危険が発生する可能性がありますので、注意してください.この属性を設定する例は以下の通りです.
'handlers': {
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler',
'include_html': True,
}
},
pythonが持っているものを除いて、djangoは2つのフィルターを提供しています.
class CallBackFilter(calback)
このフィルタは一つのコールバック関数(この関数はパラメータを受け取り、記録された情報)を受けています.各記録はフィルタを通過すると、このコールバック関数を呼び出します.コールバック関数がFalseに戻ると、この記録は処理されません.以下は一例です.
from django.http import UnreadablePostError
def skip_unreadable_post(record):
if record.exc_info:
exc_type, exc_value = record.exc_info[:2]
if isinstance(exc_value, UnreadablePostError):
return False
return True
'filters': {
'skip_unreadable_posts': {
'()': 'django.utils.log.CallbackFilter',
'callback': skip_unreadable_post,
}
},
'handlers': {
'mail_admins': {
'level': 'ERROR',
'filters': ['skip_unreadable_posts'],
'class': 'django.utils.log.AdminEmailHandler'
}
},
class Require DebugFalse
このフィルタはsettings.DEBUGがFalseである場合にのみ有効です.デフォルトは有効です.settings.DEBUG=Falseの場合にのみ、AdminEmail Handlerは有効です.
'filters': {
'require_debug_false': {
'()': 'django.utils.log.RequireDebugFalse',
}
},
'handlers': {
'mail_admins': {
'level': 'ERROR',
'filters': ['require_debug_false'],
'class': 'django.utils.log.AdminEmailHandler'
}
},
転載先:https://www.cnblogs.com/qwj-sysu/p/4218536.html