Django はそのままで動作する デフォルトのロギング設定 を持っており、すぐに拡張可能です。
\nログメッセージをコード内から送信するには、コードにロギングの呼び出しを書く必要があります。
\n\nまず、Python の logging ライブラリをインポートし、logging.getLogger() でロガーのインスタンスを取得します。getLogger() メソッドに、ロガーとロガーが出力するレコードを識別するための名前を指定します。そのための良い方法は __name__ を使用することです (これについては以下の ロガーの名前空間を使う を参照してください)。これは、次のように、現在の Python モジュールの名前をドット区切りのパスで返します。
import logging\n\nlogger = logging.getLogger(__name__)\nこの宣言はモジュール・レベルで行うのがよいとされています。
\nそして、ビューなどの関数内で、logger にレコードを送信します。
\ndef some_view(request):\n ...\n if some_risky_state:\n logger.warning("Platform is running at risk")\nこのコードが実行されると、そのメッセージを含む LogRecord が logger に送られます。Django のデフォルトの logging 設定を使っている場合、メッセージはコンソールに表示されます。
上の例で使われている WARNING レベルは、いくつかある ログの重大度レベル: DEBUG, INFO, WARNING, ERROR, CRITICAL の一つです。したがって、別の例は次のようになります。
logger.critical("Payment system is not responding")\nDjangoのロギング設定は初期状態で動作しますが、追加の設定を行うことで、ログを様々な宛先（ログファイル、外部サービス、メールなど）に送信するのを正確にコントロールできます。
\n以下のものを設定できます。
\nどのレコードがどのハンドラに送られるかを決定するためのロガーマッピング
受け取ったレコードをどう処理するかを決めるハンドラー
レコードの転送をさらにコントロールし、レコードをその場で変更することもできるフィルタ
LogRecord オブジェクトを、人間や他のシステムで利用できるように文字列や他の形式に変換するためのフォーマッタ
ロギングの設定には様々な方法があります。Django では、 LOGGING 設定が最もよく使われます。この設定は dictConfig フォーマット を使い、 デフォルトのロギング設定 を拡張します。
カスタム設定が Django のデフォルトとどのようにマージされるかについては ロギングを設定する を参照してください。
\nその他のロギングの設定方法の詳細については Python logging documentation を参照してください。簡単にするために、このドキュメントでは LOGGING 設定による設定のみを考えます。
ロギングを設定する場合、以下のようにします。
\nLOGGING 辞書を作成するLink to this heading#settings.py に以下を追加します:
LOGGING = {\n "version": 1, # the dictConfig format version\n "disable_existing_loggers": False, # retain the default loggers\n}\nほとんどの場合、 disable_existing_loggers を False に設定することで、デフォルトのロギング設定を保持し、拡張できます。
この例では、Python の FileHandler を使って、レベル DEBUG 以上のログを (プロジェクトルート内の) general.log ファイルに保存する file という名前のハンドラを設定します:
LOGGING = {\n # ...\n "handlers": {\n "file": {\n "class": "logging.FileHandler",\n "filename": "general.log",\n },\n },\n}\n異なるハンドラクラスは異なる設定オプションを取ります。利用可能なハンドラクラスの詳細については、 Django が提供する AdminEmailHandler や Python が提供する様々な handler class を参照してください。
ログレベルはハンドラで設定することもできます（デフォルトでは、ハンドラはすべてのレベルのログメッセージを受け取ります）。上の例を使うと、次のように書けます:
\n{\n "class": "logging.FileHandler",\n "filename": "general.log",\n "level": "DEBUG",\n}\nこれで、レベル DEBUG 以上のレコードだけを受け付けるようにハンドラを設定できます。
このハンドラにレコードを送信するには、ロガーマッピングをそのハンドラを使うように設定します。例えば:
\nLOGGING = {\n # ...\n "loggers": {\n "": {\n "level": "DEBUG",\n "handlers": ["file"],\n },\n },\n}\nマッピングの名前はどのログレコードを処理するかを決定します。この設定 ("") は 無名 です。つまり、 すべての ロガーからのレコードを処理します（レコードを処理するロガーを決定するためにマッピング名を使用する方法については、以下の ロガーの名前空間を使う を参照してください）。
これは DEBUG レベル以上のメッセージを file というハンドラーに転送します。
ロガーは複数のハンドラーにメッセージを転送できるので、ロガーとハンドラーの関係は多対多であることに注意してください。
\nこのコードを実行したら、:
\nlogger.debug("Attempting to connect to API")\nプロジェクトルートの general.log ファイルにそのメッセージが保存されるでしょう。
デフォルトでは、最終的なログ出力には各 log record のメッセージ部分が含まれます。追加データを含めたい場合はフォーマッタを使います。まずフォーマッタに名前を付けて定義します。この例では verbose と simple という名前のフォーマッタを定義しています:
LOGGING = {\n # ...\n "formatters": {\n "verbose": {\n "format": "{name} {levelname} {asctime} {module} {process:d} {thread:d} {message}",\n "style": "{",\n },\n "simple": {\n "format": "{levelname} {message}",\n "style": "{",\n },\n },\n}\nstyle キーワードを使用すると、 str.format() 用の { または string.Template フォーマット用の $ を指定できます。デフォルトは $ です。
含めることができる LogRecord 属性については LogRecord attributes を参照してください。
ハンドラにフォーマッタを適用するには、ハンドラの辞書に formatter エントリを追加します:
"handlers": {\n "file": {\n "class": "logging.FileHandler",\n "filename": "general.log",\n "formatter": "verbose",\n },\n}\n無名のロギング設定 "" は任意の Python アプリケーションからログを取り込みます。名前付きロギング設定は、一致する名前のロガーからだけログを取得します。
logger インスタンスの名前空間は getLogger() を使って定義します。例えば、 my_app の views.py で次のように定義します:
logger = logging.getLogger(__name__)\nこれは my_app.views 名前空間にロガーを作成します。 __name__ を使うと、プロジェクト内のアプリケーションにおけるログメッセージの出所に基づいて、自動的にそれらを整理できます。また、それによって名前の衝突が起こらなくなります。
my_app.views という名前のロガーマッピングは、このロガーからレコードを取得します:
LOGGING = {\n # ...\n "loggers": {\n "my_app.views": {...},\n },\n}\nmy_app という名前のロガーマッピングはより広く、 my_app 名前空間内のロガー（my_app.views、my_app.utils などを含む）からレコードを取得します:
LOGGING = {\n # ...\n "loggers": {\n "my_app": {...},\n },\n}\nロガーの名前空間を明示的に定義することもできます:
\nlogger = logging.getLogger("project.payment")\nそして、それに応じてロガーマッピングを設定することもできます。
\nロガーの命名は 階層的 です。 my_app は my_app.views の親であり、 my_app.views は my_app.views.private の親です。特に指定がない限り、ロガーのマッピングは処理したレコードを親に伝播（propagate）します―― my_app.views.private 名前空間のロガーからのレコードは、 my_app と my_app.views の両方のマッピングで処理されます。
この動作を管理するには、定義したマッピングに "propagate" キーを設定します:
LOGGING = {\n # ...\n "loggers": {\n "my_app": {\n # ...\n },\n "my_app.views": {\n # ...\n },\n "my_app.views.private": {\n # ...\n "propagate": False,\n },\n },\n}\npropagate のデフォルトは True です。この例では、my_app.views.private のログは親プロセスでは処理されませんが、 my_app.views のログは親プロセスで処理されます。
ロギングは、必要な情報ができるだけ多く含まれているときに最も有用であり、目的のために必要な情報だけが含まれているとなお嬉しいです。そして、必要な情報量は、あなたが何をしているかによって異なります。デバッグ中には、本番環境では過剰で役に立たないようなレベルの情報が必要になります。
\n必要な時に必要な詳細レベルを提供するように、ロギングを設定できます。これを実現するために手動で設定を変更するよりも良い方法は、環境に応じて自動的に設定を適用することです。
\n例えば、開発環境とステージング環境で環境変数 DJANGO_LOG_LEVEL を適切に設定し、ロガーマッピングで次のように使用できます:
"level": os.getenv("DJANGO_LOG_LEVEL", "WARNING")\n- 環境がより低いログレベルを指定しない限り、このコンフィギュレーションは重大度 WARNING 以上のレコードだけをハンドラに転送します。
設定の他のオプション（ハンドラの level や formatter オプションなど）も同様に管理できます。