ログ

ログ取得クイックスタート

Django は Python の組み込みの logging モジュールはログを出力します。このモジュールの使い方は、Python自身のドキュメントで詳しく説明されています。Pythonのロギングフレームワークを使ったことがない場合（あるいはあったとしても）、以下の簡単な紹介を参照してください。

ロギングの構成要素

Pythonのロギング設定は、4つの部分から構成されています。

• ロガー
• ハンドラ
• フィルター
• フォーマッタ

ロガー

Loggerは、ログ記録システムのエントリーポイントです。各ロガーは、処理する必要があるメッセージを書き込むことができる、名前の付いたコンテナです。

各ロガーには ロギングレベル . ログレベルは、ロガーが処理するメッセージの重大度を示し、Pythonは以下のログレベルを定義しています。

• DEBUG : デバッグのための基礎となるシステム情報
• INFO : 一般的なシステム情報
• WARNING : 軽微な問題であることを示す。
• ERROR : より大きな問題であることを示す。
• CRITICAL : 致命的な問題があることを示す。

ロガーに書き込まれる各メッセージは ログエントリ . また、各ログレコードは ロギングレベル これは、対応するメッセージの重要度を示します。各ログレコードは、出力されるイベントを説明する有用なメタ情報を含むこともできます。このメタ情報には、バックトラックのスタックやエラーコードなど、多くの詳細情報を含めることができます。

メッセージがロガーに渡されると、そのメッセージのログレベルとロガーのログレベルが比較されます。メッセージのログレベルがロガーのログレベルより大きいか等しい場合、メッセージはさらに下に処理されます。これより小さい場合、メッセージは無視されます。

ロガーは、メッセージを処理する必要があると判断すると、そのメッセージを ハンドラ .

ハンドラ

ハンドラは、ロガー内の各メッセージをどのように処理するかを決定します。これは、メッセージを画面、ファイル、またはネットワーク ソケットに書き込むなど、特定のロギング動作を表します。

ロガーと同様に、ハンドラにもロギング・レベルがあります。メッセージのロギング・レベルがハンドラのレベルより低い場合、ハンドラはそのメッセージを無視します。

ロガーは複数のハンドラを持つことができ、各ハンドラは異なるログレベルを持つことができます。このアプローチを使用すると、メッセージの重要性に応じて、異なる形式の処理を提供することができます。たとえば、あるハンドラで ERROR と CRITICAL をページサービスに送信するハンドラと，すべてのメッセージ( ERROR と CRITICAL メッセージ)をファイルに記録し、後で分析することができます。

フィルター

フィルターは、ロガーからハンドラーに渡されるログレコードをさらに制御するために使用されます。

デフォルトでは、ロギングレベルを満たしたメッセージはすべて処理されます。フィルターを設置することで、ログ処理に条件を追加することができます。例えば、特定のソースからのメッセージの処理のみを許可するフィルタをインストールすることができます。 ERROR のメッセージを表示します。

また、フィルターは、処理されるログレコードの優先順位を変更するために使用することができます。例えば、ログレコードが特定の条件を満たす場合、ログレコードの優先順位を次のように変更するフィルタを書くことができます。 ERROR から WARNING .

フィルターは、ロガーまたはハンドラーにインストールできます。複数のフィルターを連結して、フィルターの動作を多層化することができます。

フォーマッタ

最後に、ログレコードはテキストに変換される必要があります。フォーマッタはテキストのフォーマットを表します。 ログレコード属性 は、Python フォーマットの文字列で構成されています。独自のフォーマットを実装するために、カスタムの fomatter を書くこともできます。

ロギングを利用する

ロガー、ハンドラ、フィルタ、フォーマッタを設定した後、コードにロギングコールを記述する必要があります。ロギングフレームワークを使うのはとても簡単です。以下はその例です。

# 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!')

それだ！を満たすたびに bad_mojo の条件が満たされると、エラーログエントリーが書き込まれます。

ロガーの命名

logging.getLogger() この呼び出しは、名前によって識別されるロガーのインスタンスを取得（必要に応じて作成）します。

Logger の名前は、慣例的に次のように使用されます。 __name__ は、ロガーを含むPythonモジュールの名前です。これにより、モジュールベースのフィルタリングやロギングコールを処理することができます。もし、他の方法でログメッセージを整理したい場合は、ロガーを識別するためにドット区切りの名前を提供することができます：。

# Get an instance of a specific named logger
logger = logging.getLogger('project.interesting.stuff')

ドットで区切られたロガー名で階層を定義します。 project.interesting ロガーは project.interesting.stuff より上位のロガーです。 project ロガーは project.interesting loggerは、その上のレベルの

なぜ、このような階層構造になっているのでしょうか？なぜなら、ロガーを設定することで を伝搬させる のロギング・コールをその親レベルへ転送します。この方法で、ルート・ロガーに一連のハンドラを定義し、子ロガーですべてのロギング呼び出しを捕捉できます。また project 名前空間は project.interesting と project.interesting.stuff ロガーに記録されるすべてのログメッセージ

この伝搬の動作は、ロガーごとに制御することができます。ロガーがその上位レベルにメッセージを伝搬させたくない場合、この動作をオフにすることができます。

ロギングコール

Logger インスタンスは、各デフォルトのロギングレベルに対してエントリメソッドを提供します。

• logger.debug()
  

の呼び出しは他に2つあります。

• logger.info() : メッセージ印刷時に手動でロギングレベルを指定します。
• logger.warning() : を作成します。 logger.error() レベルのログメッセージで、例外スタックの現在のフレームをカプセル化します。

ロギングを設定する

もちろん、コードにログの呼び出しを入れるだけでは十分ではありません。ログの出力が意味を持つように、ロガー、ハンドラ、フィルタ、フォーマッタを設定する必要があります。

Pythonのロギングライブラリは、ロギングを設定するために、プログラム的なインタフェースから設定ファイルまで、いくつかのテクニックを提供しています。デフォルトでは、 Django は dictConfig 形式 .

ロギングを設定するためには logger.critical() を使用して、ロギング設定を辞書形式で定義します。これらの設定は、ロギング設定のロガー、ハンドラ、フィルタ、フォーマッタ、およびそれらのロギングレベルやその他のプロパティを記述します。

デフォルトでは logger.log() と同じ設定にします。 Django のデフォルトのロギング設定 マージを実行します。

もし logger.exception() で ERROR キーは LOGGING （ロガーは存在しますが、ロガーに渡された情報はすべて静かに破棄され、上位のロガーに伝搬されないためです。 LOGGING それはあなたが望むものではない可能性があります。この場合 LOGGING から disable_existing_loggers を設定し、デフォルトのロガーの一部または全部を再定義します。 True に対して 'disable_existing_loggers': True と ログ取得の設定を自分で行う .

Loggingの設定はDjangoに属します。 disable_existing_loggers 関数を使用します。ですから、あなたのプロジェクトのコードでロガーが常に利用可能であることを確認することができます。

例

dictConfigの形式 ロギング・ディクショナリー・コンフィギュレーションについては、完全なドキュメントが最良の情報源です。しかし、味わうために、ここにいくつかの例を挙げます。

まず、簡単な設定ですが、このように django.request（ジャンゴ・リクエスト loggerに対するすべてのロギングリクエストはローカルファイルに書き込まれます。

False

この例を使用する場合は、必ず LOGGING_CONFIG のパスを、Django アプリを実行しているユーザが書き込み権限を持つ場所に設定します。

次に、以下の例では、ロギングシステムで Django のログをコンソールに出力させる方法を示しています。 None と setup() は、ログを上位に伝搬させません。ローカル開発時には便利かもしれません。

デフォルトでは、この設定は LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'file': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': '/path/to/django/debug.log', }, }, 'loggers': { 'django.request': { 'handlers': ['file'], 'level': 'DEBUG', 'propagate': True, }, }, } Django にはこのようなログメッセージはあまりありません。環境変数 'filename' Django のデバッグログを見てみましょう。すべてのデータベースクエリを含んでいるので、とても詳細です。

django.request

最後に、かなり複雑なロギング設定を紹介します。

django.security

このロギング設定は、以下のことを行います。

• dictConfig version 1」形式の設定をパースします。今のところ、dictConfig 形式のバージョンはこれだけです。

• 2つのフォーマッタを定義する。

  • INFO というように、ログのレベルのみを出力するものです（例えば DJANGO_LOG_LEVEL=DEBUG ) とログメッセージを表示します。

    import os LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'console': { 'class': 'logging.StreamHandler', }, }, 'loggers': { 'django': { 'handlers': ['console'], 'level': os.getenv('DJANGO_LOG_LEVEL', 'INFO'), }, }, } この文字列は、各ログ行の詳細を記述した、通常のPython形式の文字列です。出力の全詳細は フォーマッタ・ドキュメント で見つけることができます。

  • LOGGING = { 'version': 1, 'disable_existing_loggers': False, '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', 'foo': 'bar', } }, 'handlers': { 'null': { 'level': 'DEBUG', 'class': 'logging.NullHandler', }, 'console': { 'level': 'DEBUG', 'class': 'logging.StreamHandler', 'formatter': 'simple' }, 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log, 'filters': ['special'] } }, 'loggers': { 'django': { 'handlers': ['null'], 'propagate': True, 'level': 'INFO', }, 'django.request': { 'handlers': ['mail_admins'], 'level': 'ERROR', 'propagate': False, }, 'myproject.custom': { 'handlers': ['console', 'mail_admins'], 'level': 'INFO', 'filters': ['special'] } } } ログレベル、ログメッセージ、ログメッセージを生成した時間、プロセス、スレッド、モジュールが出力されます。

• フィルタを定義する --。 simple というエイリアスを使用します。 DEBUG . もしフィルタが構築中に追加のパラメータを必要とするなら、フィルタの設定フィールドに追加のキーで提供することができます。この例では、フィルタのインスタンスを作成した後で format というときに verbose の値が使われます。 project.logging.SpecialFilter .

• 3つのハンドラを定義します。

  • special を渡すNullHandlerが必要です。 SpecialFilter (およびより高度な) メッセージを foo .
  • bar を表示する StreamHandler です。 null (およびより高度な) メッセージを標準エラー出力に出力します。このハンドラは DEBUG の出力形式です。
  • /dev/null AdminEmailHandler は、メッセージに console (およびより高度な) メッセージをサイト管理者に送信します。このハンドラは DEBUG フィルタを使用します。

• 3つのロガーを設定します。

  • simple これは、すべての mail_admins とより高度なメッセージは ERROR ハンドラです。
  • special これは、すべての django へのメッセージは INFO また、このロガーをマークする ではない は、メッセージを上方に伝播させます。つまり null によって伝播されることはありません。 django.request logger を使用します。
  • ERROR これは、すべての mail_admins といった高度なメッセージは django.request は、両方のハンドラにメッセージをフィルタリングします。 django と myproject.custom . これは、すべての INFO (およびより高度な) メッセージがコンソールに出力されます。 special と console のメッセージは、メールでも配信されます。

カスタムロギング設定

ロガーの設定に Python の dictConfig 形式を使いたくない場合、独自の設定モードを指定することができます。

mail_admins Django のロガーを設定するために使われる呼び出し可能なオブジェクトを設定し ます。 INFO 関数を使用します。しかし、別の設定手順を使いたい場合は、引数を1つだけ取る他の呼び出し可能なオブジェクトを使用することができます。ロギングを設定するときには ERROR の中身は

ロギングを無効にする設定

ロギングを全く設定したくない場合（あるいは独自の方法で手動でロギングを設定したい場合）は CRITICAL について LOGGING_CONFIG . これは Django のデフォルトのロギング 設定作業の様子です。以下の例では、Django のロギング設定を無効化し、手動でロギングを設定します。

設定.py

logging.config.dictConfig()

を設定します。 LOGGING に対して LOGGING_CONFIG は、自動設定処理を無効にすることを意味するだけで、ロギングそのものを無効にするわけではありません。設定処理を無効にしても、 Django はロギングの呼び出しを行い、デフォルトで定義されているロギング動作を 呼び出すだけです。

Django のロギング拡張機能

Django は、Web サーバ環境におけるユニークなロギングニーズを処理するためのツールを多数提供しています。

ロガー

Django はいくつかの組み込みロガーを提供します。

ジャンゴ

None は、すべてのメッセージを取得するロガーです。メッセージは、このロガーに直接送信されません。

django.request（ジャンゴ・リクエスト

リクエストの処理に関連するメッセージをログに記録します。5XXレスポンスとして LOGGING_CONFIG = None import logging.config logging.config.dictConfig(...) メッセージとして記録され、4XXレスポンスは LOGGING_CONFIG メッセージになります。

このロガーのメッセージには、以下の追加コンテキストがあります。

• None : リクエストの HTTP レスポンスコードです。
• django : ログメッセージを生成するリクエストオブジェクト。

django.db.バックエンド

データベースと相互作用するコードに関連するメッセージ。例えば、アプリケーションレベルの SQL 文を実行するための HTTP リクエストは、次のように始まります。 ERROR レベルがこのロガーに記録されます。

このロガーのメッセージは、以下の追加コンテキストを持ちます。

• WARNING : SQL文の実行にかかった時間です。
• status_code : 実行する SQL 文です。
• request : SQL呼び出しで使用されるパラメータ。

パフォーマンス上の理由から、SQL ログの記録は DEBUG DEBUGが設定されている duration ロギング・レベルやインストールされているプロセッサに関係なく。

ここでのロギングには、フレームワークレベルの初期化（例えば sql ) やトランザクション管理クエリ (例. params , set と True ). すべてのデータベースクエリを見たい場合は、データベースのクエリログを開くことができます。

django.security.*

セキュリティロガーは SET TIMEZONE SuspiciousOperationの各サブタイプにはサブロガーがあります。ロギングのレベルは、例外がどこで処理されるかに依存します。ほとんどの場合、WARNING ログになりますが、もし BEGIN は、WSGIハンドラに到達した場合、エラーとしてログに記録されます。例えば、リクエストにHTTP COMMIT ヘッダは ROLLBACK が一致しない場合、Django は 400 レスポンスを返し、エラーメッセージも SuspiciousOperation ロガーに保存されます。

デフォルトでは SuspiciousOperation ロガー、および他のすべての子ロガーは、より高いレベルのロガーに伝搬されます。 Host ロガーの構成は ALLOWED_HOSTS ロガーで、エラーメッセージはサイト管理者に電子メールで送信されます。このため django.security.DisallowedHost を使用すると、400 レスポンス・リクエストを送信しないよう django.security ロガーに記録されますが django.security logger を使用します。

特定のタイプの SuspiciousOperation を黙って破棄するには、次の例のようにそのロガーをオーバーライドすることができます。

django.request

django.db.backends.schema

Django 1.7 の新機能です。

いつ マイグレーションフレームワーク 実行されたSQLクエリがデータベースのスキーマを変更した場合にログを記録します。を記録しないことに注意してください。 SuspiciousOperation 実行するクエリ。

ハンドラ

Python logging モジュールが提供するハンドラに加えて、Django はもう一つ のハンドラを提供します。

クラス django.request ( include_html=False , email_backend=なし ) [ソース］

このハンドラは、受け取ったログメッセージをサイト管理者にメールで送信します。

ログレコードに django.security 属性を使用すると、リクエストの全詳細がメッセージに含まれます。

ログレコードにスタックトレースバック情報が含まれている場合、そのスタックトレースバックもメッセージに含まれます。

'loggers': { 'django.security.DisallowedHost': { 'handlers': ['null'], 'propagate': False, }, }, は RunPython パラメータは、メールに含まれる HTML 添付ファイルが AdminEmailHandler に対して request の場合、全ページが利用可能です。この値を設定するためには、設定ファイルの中にある AdminEmailHandler ハンドラの定義に、以下のように記述します。

include_html

メールの HTML には、スタックの各レベルのローカル変数の名前と値、そして Django の設定を含む、完全なトレースバックスタックが含まれていることに注意してください。この情報は非常に機密性が高いので、電子メールで送りたくないかもしれません。この時点で、次のようなものを使うことを検討してください セントリー スタックの全情報とセキュリティ情報に戻る、次のようなものです。 はしません。 をメールで送信します。また、エラーレポートから特定の機密情報を明示的に除外することもできます -- 詳細は以下を参照してください。 エラーレポートのフィルタリング .

を設定することで DEBUG の True パラメータをオーバーライドすることができます。 メールバックエンド このように

django.utils.log.AdminEmailHandler

デフォルトでは 'handlers': { 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log, 'include_html': True, } }, で指定されたメールバックエンドは

AdminEmailHandler ( 件名 , メッセージ , *args , **kwargs ) [ソース］

Django 1.8 の新機能です。

管理者ユーザーにメールを送信します。その動作をカスタマイズするために、サブクラスの email_backend クラスを作成し、このメソッドをオーバーライドします。

フィルター

Python logging モジュールが提供するフィルタに加え、Django はさらに 2 つのフィルタを提供します。

クラス 'handlers': { 'mail_admins': { 'level': 'ERROR', 'class': 'django.utils.log, 'email_backend': 'django.core.mail.backends.filebased.EmailBackend', } }, ( コールバック ) [ソース]です。

このフィルタはコールバック関数（ログに記録される内容を1つの引数として取る）を受け取り、フィルタに渡された各レコードに対してコールバック関数を呼び出します。コールバック関数がFalseを返した場合、そのレコードの処理は行われません。

例えば、管理者メールをフィルタリングするために EMAIL_BACKEND (ユーザがアップロードをキャンセルしたときのみ生成される)フィルタ関数を作成します。

send_mail

そして、ロガーの設定に追加します。

AdminEmailHandler

クラス CallbackFilter [ソース]です。

このフィルタは設定された後のレコードのみを通過させます。

このフィルタは UnreadablePostError を確保するためのデフォルトの設定です。 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' } }, に対して RequireDebugFalse はエラーメッセージを送信します。

LOGGING

クラス AdminEmailHandler [ソース]です。

このフィルタは DEBUG ただし、レコードは False に対して 'filters': { 'require_debug_false': { '()': 'django.utils.log.RequireDebugFalse', } }, 'handlers': { 'mail_admins': { 'level': 'ERROR', 'filters': ['require_debug_false'], 'class': 'django.utils.log.AdminEmailHandler' } }, を渡すと

Django のデフォルトのロギング設定

デフォルトでは、Django のロギング構成は以下のようになっています。

いつ RequireDebugTrue について RequireDebugFalse いつ

• DEBUG グローバルロガーは、コンソールに True Django はこの時、ロギングの呼び出しを行いません (すべてのメッセージは DEBUG レベル、または True と django (処理されたログ)です。
• INFO のデータを処理するロガーです。 DEBUG であり、コンソールにメッセージを送信する。

を実行すると django.request に対して django.security いつ

• py.warnings と warnings.warn() ロガーを DEBUG でメッセージを送信します。 False または django.request レベルのメッセージになります。これらのロガーは、以下のレベルのメッセージを無視します。 django.security メッセージは、ログに記録されたログは他のロガーに渡されることはありません（それらは AdminEmailHandler のグローバルロガーを使用する場合、たとえ ERROR は CRITICAL ).

こちらもご覧ください コンフィギュレーションログ を参照して、デフォルトのロギング設定を補足したり置き換えたりする方法を学んでください。

<ブロッククオート

翻訳者です。 Django ドキュメンテーション共同翻訳グループ 元はといえば ロギング .

この記事は cc by-nc-sa 3.0 この記事の著者名と出典を保持してください。

Django ドキュメンテーション共同翻訳グループ 人手が足りないので、興味のある方は参加してみてください、完全公募制です。交流グループです。467338606.