Django の logging モジュールは Python の 組み込み logging モジュールを継承しています。
Logging は、一般的なDjangoの django.setup() 関数の一部として設定されているため、明示的に無効にされない限り常に利用可能です。
デフォルトでは、Django は Python の logging.config.dictConfig フォーマット を使用します。
\nデフォルトのログ記録条件の完全なセットは以下の通りです:
\nDEBUG が True のとき:
django ロガーは、django ヒエラルキー (django.server を除く) において、INFO レベル以上のメッセージをコンソールに送信します。
DEBUG が False のとき:
django ロガーは、django ヒエラルキー (django.server を除く) において、ERROR ないし CRITICAL レベルを AdminEmailHandler に送信します。
DEBUG の値にかかわらず:
django.server ロガーは INFO レベル以上のメッセージをコンソールに送信します。
django.server を除く全てのロガーは、ルートの django ロガーまで、親に対してログを伝播させます。console と mail_admins ハンドラは、上述の動作を提供するためにルートロガーにアタッチされます。
Pythonのデフォルトは、レベル WARNING 以上のレコードをコンソールに送ります。
Django のデフォルトのロギング設定は、Python のデフォルトを継承しています。これは django.utils.log.DEFAULT_LOGGING として利用可能で、 django/utils/log.py で定義されています。
{\n "version": 1,\n "disable_existing_loggers": False,\n "filters": {\n "require_debug_false": {\n "()": "django.utils.log.RequireDebugFalse",\n },\n "require_debug_true": {\n "()": "django.utils.log.RequireDebugTrue",\n },\n },\n "formatters": {\n "django.server": {\n "()": "django.utils.log.ServerFormatter",\n "format": "[{server_time}] {message}",\n "style": "{",\n }\n },\n "handlers": {\n "console": {\n "level": "INFO",\n "filters": ["require_debug_true"],\n "class": "logging.StreamHandler",\n },\n "django.server": {\n "level": "INFO",\n "class": "logging.StreamHandler",\n "formatter": "django.server",\n },\n "mail_admins": {\n "level": "ERROR",\n "filters": ["require_debug_false"],\n "class": "django.utils.log.AdminEmailHandler",\n },\n },\n "loggers": {\n "django": {\n "handlers": ["console", "mail_admins"],\n "level": "INFO",\n },\n "django.server": {\n "handlers": ["django.server"],\n "level": "INFO",\n "propagate": False,\n },\n },\n}\nこのデフォルトのロギング設定を補完または置換する方法については、ロギングを設定する を参照してください。
\nDjangoは、Web サーバー環境でのロギングの特別な要件を処理するための多数のユーティリティを提供しています。
\nDjangoはいくつかの組み込みロガーを提供しています。
\ndjangoLink to this heading#django 名前付きロガー階層 のメッセージの親ロガーです。 Djangoは、この名前を使用してメッセージを投稿しません。代わりに、以下のロガーのいずれかを使用します。
django.requestLink to this heading#リクエストに関するログをハンドリングします。5XXレスポンスは ERROR メッセージとして送られ、 4XXレスポンスは WARNING メッセージとして送られます。 django.security ロガーに出力されたメッセージは、 django.request ロガーには送られません。
このロガーに送られるメッセージには、以下のようなコンテキストが含まれます。
\nstatus_code: リクエストに対するレスポンスのHTTPレスポンスコード。
request: ログのメッセージに対応するリクエストのオブジェクト。
django.serverLink to this heading#runserver コマンドによって立ち上がったサーバーが受け取ったリクエストに関するログメッセージ。HTTP の 5XX レスポンスは ERROR メッセージとして送られ、 4XX レスポンスは WARNING メッセージとして送られ、その他は INFO メッセージとして送られます。
このロガーに送られるメッセージには、以下のようなコンテキストが含まれます。
\nstatus_code: リクエストに対するレスポンスのHTTPレスポンスコード。
request: ログメッセージを生成したリクエストオブジェクト (socket.socket) 。
django.templateLink to this heading#テンプレートのレンダリングに関するログメッセージ。
\nコンテキストに変数が無い場合は DEBUG メッセージとして送られる。
django.db.backendsLink to this heading#コードとデータベースの間でのやりとりに関するメッセージ。たとえば、アプリケーションから実行全ての SQL は DEBUG レベルでメッセージが送られます。
このロガーに送られるメッセージには、以下のようなコンテキストが含まれます。
\nduration: SQLを実行するのにかかった時間。
sql: 実行されたSQL文。
params: SQLの呼び出しに使ったパラメータ。
alias: SQL 呼び出しで使用されるデータベースのエイリアス。
パフォーマンスの観点から、 SQL ログは、ログレベルやハンドラに関わらず、 settings.DEBUG に True が設定されているときのみ有効になります。
このログには、フレームワークレベルの初期化(例: SET TIMEZONE) は含まれていません。すべてのデータベースクエリを表示したい場合は、データムベースでクエリログを有効にしてください。
django.utils.autoreloadLink to this heading#Django 開発サーバー実行中の自動コードリロードに関連するログメッセージです。このロガーは、ソースコードファイルの変更を検出した際に INFO メッセージを生成し、ファイルシステムの検査やイベント購読プロセス中に WARNING メッセージを生成することがあります。
django.contrib.authLink to this heading#django.contrib.auth に関連するログメッセージ、特に ERROR メッセージは、PasswordResetForm が正常に送信されたが、メール送信例外によりパスワードリセットメールが配信できなかった場合に生成されます。
django.contrib.gisLink to this heading#GeoDjango に関連するログメッセージは、外部の地理空間ライブラリ（GEOS、GDALなど）の読み込み時や、エラーを報告する時点で様々な場所に記録されます。各 ERROR ログレコードには、発生した例外と関連するコンテキストデータが含まれます。
django.dispatchLink to this heading#このロガーは シグナル において使用されており、特に Signal クラス内で、接続されたレシーバへのシグナルのディスパッチ時に問題が発生した場合に報告するために使用されます。ERROR ログレコードには捕捉された例外が exc_info として含まれ、以下の追加コンテキストが加えられます。
receiver: レシーバの名前。
err: レシーバを呼び出した時に発生した例外。
django.security.*Link to this heading#セキュリティログは、 SuspiciousOperation および他のセキュリティ関連のエラーが発生した際にメッセージを受け取ります。セキュリティエラーの各サブタイプごとにサブロガーがあり、すべての SuspiciousOperation が含まれます。ログイベントのレベルは、例外が処理される場所によって異なります。ほとんどの発生は警告としてログされますが、WSGIハンドラーに到達した SuspiciousOperation はエラーとしてログされます。たとえば、クライアントからのリクエストに含まれるHTTP Host ヘッダーが ALLOWED_HOSTS と一致しない場合、Djangoは400のレスポンスを返し、django.security.DisallowedHost ロガーにエラーメッセージがログされます。
これらのログイベントはデフォルトで django ロガーに到達し、DEBUG=False のときにはエラーイベントを管理者にメールします。SuspiciousOperation によって400レスポンスを引き起こすリクエストは django.request ロガーには記録されず、django.security ロガーにのみ記録されます。
特定のタイプの SuspiciousOperation を無視するには、以下の例に従って、その特定のロガーをオーバーライドできます:
LOGGING = {\n # ...\n "handlers": {\n "null": {\n "class": "logging.NullHandler",\n },\n },\n "loggers": {\n "django.security.DisallowedHost": {\n "handlers": ["null"],\n "propagate": False,\n },\n },\n # ...\n}\nSuspiciousOperation に基づかない他の django.security ロガーには、以下があります:
django.security.csrf: CSRF の失敗 に関するもの。
django.db.backends.schemaLink to this heading#スキーマの変更中に実行されるSQLクエリを、 マイグレーションフレームワーク によってログ記録します。ただし、 RunPython によって実行されるクエリはログされません。このロガーへのメッセージには、 params と sql が追加のコンテキストとして含まれます（ただし、 django.db.backends とは異なり、実行時間は含まれません）。これらの値の意味については、 django.db.backends で説明されている内容と同じです。
django.contrib.sessionsLink to this heading#セッションフレームワーク に関連するログメッセージです。
\ndjango.contrib.sessions.backends.cached_db.SessionStore エンジンを使用している際に発生する非致命的なエラーは、ERROR メッセージとして、対応するトレースバックとともにログに記録されます。
Django は、 Pythonのモジュールによって提供されるもの に加えて、1つのログハンドラを提供しています。
このハンドラは、受け取ったログメッセージごとにサイトの ADMINS に電子メールを送信します。
ログレコードに request 属性が含まれている場合、リクエストの詳細がメールに含まれます。クライアントの IP アドレスが INTERNAL_IPS 設定にある場合、メールの件名に "internal IP" というフレーズが含まれます。そうでない場合は "EXTERNAL IP" が含まれます。
ログレコードにスタックトレース情報が含まれている場合、そのスタックトレースは電子メールに含まれます。
\nAdminEmailHandler の include_html 引数は、 DEBUG が True の場合に生成されるデバッグウェブページの内容を含む HTML 添付ファイルを traceback メールに含めるかどうかを制御するために使用されます。この値を設定するには、django.utils.log.AdminEmailHandler のハンドラ定義に含めます。以下のようになります:
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "include_html": True,\n },\n}\nAdminEmailHandler を使用する際は、 ログのセキュリティ上の注意点 に注意してください。
AdminEmailHandler の email_backend 引数を設定することで、ハンドラーが使用している メールバックエンド を以下のように上書きできます:
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "email_backend": "django.core.mail.backends.filebased.EmailBackend",\n },\n}\nデフォルトでは、 EMAIL_BACKEND で指定されたメールバックエンドのインスタンスが使用されます。
AdminEmailHandler の reporter_class 引数では、メール本文で送信されるトレースバックテキストをカスタマイズするために django.views.debug.ExceptionReporter サブクラスを提供できます。使用したいクラスへの文字列インポートパスをこのように指定します:
"handlers": {\n "mail_admins": {\n "level": "ERROR",\n "class": "django.utils.log.AdminEmailHandler",\n "include_html": True,\n "reporter_class": "somepackage.error_reporter.CustomErrorReporter",\n },\n}\n管理ユーザーにメールを送信します。この動作をカスタマイズするためには、 AdminEmailHandler クラスをサブクラス化して、このメソッドをオーバーライドできます。
Djangoは、Pythonのロギングモジュールによって提供されるフィルタに加えて、いくつかのログフィルタを提供しています。
\nこのフィルタは、(1 つの引数、ログを行うレコード) を受け入れるコールバック関数を受け入れ、フィルタを通過する各レコードに対してその関数をコールします。コールバックが False を返す場合、そのレコードの処理は進みません。
\n例えば、管理者メールから（ユーザーがアップロードをキャンセルした時に発生する） UnreadablePostError をフィルタリングするために、フィルタ関数を作成します。
from django.http import UnreadablePostError\n\n\ndef skip_unreadable_post(record):\n if record.exc_info:\n exc_type, exc_value = record.exc_info[:2]\n if isinstance(exc_value, UnreadablePostError):\n return False\n return True\n次に、ログ設定にそれを追加します:
\nLOGGING = {\n # ...\n "filters": {\n "skip_unreadable_posts": {\n "()": "django.utils.log.CallbackFilter",\n "callback": skip_unreadable_post,\n },\n },\n "handlers": {\n "mail_admins": {\n "level": "ERROR",\n "filters": ["skip_unreadable_posts"],\n "class": "django.utils.log.AdminEmailHandler",\n },\n },\n # ...\n}\nこのフィルタは、settings.DEBUG が False の時のみ、レコードを通過させます。
このフィルタは、デフォルトの LOGGING 設定で以下のように使用され、 DEBUG が False のときのみ AdminEmailHandler がエラーメールを管理者に送信するようにします:
LOGGING = {\n # ...\n "filters": {\n "require_debug_false": {\n "()": "django.utils.log.RequireDebugFalse",\n },\n },\n "handlers": {\n "mail_admins": {\n "level": "ERROR",\n "filters": ["require_debug_false"],\n "class": "django.utils.log.AdminEmailHandler",\n },\n },\n # ...\n}\nこのフィルタは RequireDebugFalse に似ていますが、DEBUG が True の場合にのみレコードが渡されます。