2012-03-06 5 views
2

私はDjangoを使用してAPIを作成しています。すべてのビューはJSONで応答します。私は各HttpResponse JSONをdevサーバーの出力に記録したいと思います。Django開発ログデバッガサーバーへのHttpResponses

は、これまでのところ私は、ハンドラを追加しました:その後、

'console': { 
     'level':'DEBUG', 
     'class':'logging.StreamHandler', 
} 

とは、ロガーを追加しました:

'to_console': { 
     'handlers': ['console'], 
     'level': 'DEBUG', 
    } 

私の見解では、私はロガーlogger = logging.getLogger('to_console')

と各JSONレスポンスのための取得logger.debug(json_str)

最初のビューでこれは問題ありませんでした。しかし、私はそれが生産にアプリを展開するときにデバッグをオフにすることが可能ですか? https://docs.djangoproject.com/en/dev/topics/logging/#django.utils.log.RequireDebugFalseがうまくいくようです。しかし、それはこれらのロギングステートメントで散らばって私のコードをリードします。私はこれのような何かをログに記録する必要はありませんでしたので、私はそれを扱う最も保守的な方法が何であるか疑問に思っています。

開発ロギングを処理して、コードが実稼働中に「オフ」になる正しい方法は何ですか?または、私は、自動的にすべてのHttpResponseをdevサーバーに記録していない、ある種の機能やアプリケーションをビルドしていますか?

答えて

2

ロギングに提供する設定を変更することで、ロギング機能をオフ/オンにすることができます。ロギングステートメントはコードを「浪費する」ものと考えるかもしれませんが、サーバーが運用環境で動作すると、ロギング以外に、内部で何が起こっているかを知る方法はほとんどありません。

必要に応じて、実行中のサーバーに新しい構成を含むJSONデータを送信することができます。このデータは、POST要求を処理するビューによって有効になります。しかし、ロギングステートメントをそのまま残しておきましょう。ロギングレベルが実際には何も出力されないような場合にはかなり安いからです(実際にはコンソール/ファイル/ソケットなどへの書き込みの実際のI/Oはレベルが十分高く設定されていれば、実際にはほとんど出力されません)。

開発とテストではすべて正常に動作しますが、実際には実働環境では失敗すると、ログが唯一の診断ツールとなることがあります。

私はRequireDebugFalseの使用は、あなたが記述したシナリオではかなり合理的だと思いますが、独自のフィルタを書くこともできます(フィルタの作成は非常に簡単です)。

関連する問題