プロジェクトマネージャーのように機能する Django を使用してアプリケーションを開発しています。このため、システムはすべての情報を保存できる必要があります。ユーザーが行うアクション、アクションの実行中に発生したエラーなどについて言及するとき、私はクラス Log を持っており、その属性の 1 つは action_type と呼ばれます。この属性は、発生したアクションの種類を指定します。私は5種類のタイプを持っているはずです：
情報:このログには、プロジェクトの作成、他のユーザーの作成など、ユーザーのアクションに関連する情報が保存されます。
DEBUG:開発者が作成したコメントを保存して、エラーを検出できるようにする必要があります。
エラー:システムで発生したエラーを示しますが、システムの機能には影響しません。
警告:損害を与える可能性のあるアクション用です。
FATAL:予期しないエラー、例外、およびセキュリティ違反。
INFO の論理ログしか思いつきません。
このカテゴリや他のカテゴリに含めるべき妥当なログをいくつか教えていただけますか?
答えは、アプリケーションが何をするかによって大きく異なりますが、私の基本的なアプローチは次のとおりです。
イベントをログに記録する準備が整うたびに、そのイベントについて考えるだけで、そのイベントがどこに属しているかが明確になります。それはあなたのアプリケーションを殺しましたか？致命的です。それは何かが正しく機能するのを妨げましたか? エラーです。何かが機能しなくなる可能性がありますか?今回は運が良かったのでしょうか? 警告です。誰も気にしませんか？情報。それ以外の場合でもログに記録する必要がある場合は、デバッグ目的である必要があります。
特定のコンテキストでは、ユーザー アクションをログに記録しようとしているだけのように思えます。その場合、致命的な可能性がある唯一のアクションは、元に戻すオプションを提供しないアクションです (または、ユーザーがピアノのベンチと強力なロープを注文できる場合)応用）。また、ユーザーの操作からデバッグ レベルのログが生成されることも想像できませんでした。このため、ユーザー アクションに加えて、コード レベルのイベントをログに記録することになると思います。
FATAL:これは、アプリケーションが実際にクラッシュしたときにのみログに表示され、500 の応答と一緒に表示される可能性があります。プロセスが停止していた場合にのみ、wsgi アプリケーション内でキャッチオールとしてこれらを生成することができます。
ERROR: HTTP エラー応答に関連している可能性があります。これは通常、アプリケーションの外部で発生したエラーです。コード内で発生することは、おそらく予想され、警告レベル以下であるか、予想外で致命的です。エラーは、ユーザーによる URL のタイプミス、フォーム送信時の検証エラー、または認証エラーによる 404 である可能性があります。他の方向からは、接続したリモート Web サービスからエラーが返されたり、OS から IO エラーが返されたりする可能性があります。
警告:何も壊さないものの、そのままにしておくと噛まれる可能性があるもの。例では、非推奨の API を使用しており、デフォルト (タイム ゾーン、文字エンコーディングなど) が原因でしか機能しないものを使用しています。過去の期日を設定するなど、特定の入力値でも警告が発生する場合があります。
情報:一般的で正常な動作です。誰かがデータベース行 (新しいプロジェクトまたはタスク?) を作成した、アカウントを作成した、ログインまたはログアウトした、ソケットが正常に開かれた、など。
デバッグ:まさにそのとおりです。コードが正しく機能するようになったら、通常はオフにする出力。メソッドの開始/終了、オブジェクトのインスタンス化、コード内のさまざまなポイントでのフィールド値、カウンター。作業中に、プログラムが現在クラッシュしている理由を理解するために必要なものは何でも。