debugging - ロギングとデバッグ

Question

背景: ローカル機器とリモート機器の間でオンザフライ接続を作成するための Web アプリケーションを継承しました。最近、非常に多くの可動部分があります。アプリ自体が大幅に変更されました。開発ツールチェーンが更新されました。そして、これらの変更をサポートするために、ローカル機器とリモート機器の両方が「変更」されています。

明るい面は、デバッグ メッセージをファイルに書き込む適切なログ システムがあり、ファイルとリアルタイムのユーザー画面の両方にログを記録することです。ログ/デバッグ メカニズム全体を作り直す機会があります。

例:

• すべてのメッセージにはタイムスタンプが付けられ、重大度のプレフィックスが付けられます。
• ログはお客様用です。彼らは、彼/彼女の要求に対するシステムの応答を記録します。
• 問題を特定するログには、解決策も示されます。
• デバッグは、開発者および技術サポート向けです。それらはシステムの内部を明らかにします。
• デバッグは、それらを生成した関数や行を示します。
• 顧客は、その場でデバッグ レベルを調整して詳細度を設定できます。

質問:有用なログとデバッグを生成する、開発者として使用した、または消費者として見たベスト プラクティスは何ですか?

---

編集：これまでに多くの役立つ提案、ありがとう！明確にするために：私は、特定のツールよりも、何をログに記録するか、つまりコンテンツ、形式など、およびそうする理由に関心があります。

これまでに見たログの中で、最も役に立ったのはどのような点でしたか?

ご協力いただきありがとうございます！

Answer 1

Logging、Tracing、および Error Reporting を混同しないでください。私の知っている何人かは混同していて、必要な情報を取得するために grep するためのログ ファイルが作成されます。

すべてを大量生産したい場合は、次のように分けます。

• トレース-> すべてのアクションとステップをダンプし、タイムスタンプを付けて、そのステージの入力データと出力データを使用します (最も醜い最大のファイル)
• ロギング-> ビジネス プロセス ステップのみをログに記録します。クライアントは照会を行うため、照会条件をログに記録し、データを出力することはありません。
• エラー報告/デバッグ-> 発生場所、タイムスタンプ、可能な場合は入力/出力データ、ユーザー情報などの詳細をログに記録した例外

そうすれば、エラーが発生し、エラー/デバッグ ログに好みの十分な情報が含まれていない場合、いつでもgrep -A 50 -B 50 'timestamp' tracing_file詳細を取得することができます。

編集: 言われているように、例として Python 用のビルトイン ロギング モジュールのような標準パッケージに固執することは常に良いことです。言語の標準ライブラリに含まれていない限り、自分で作成することは良い考えではありません。私は、ロギングを小さな関数でラップするのが好きです。一般的に、どのログに行くかを決定するためのメッセージと値を取ります。1 - トレース、2 - ロギング、4 - デバッグなので、値 7 を送信すると 3 などすべてにドロップされます。

Answer 2

ロギングフレームワークで行われる最も価値のあることは、アプリケーションが顧客のマシンにデプロイされている場合でも、すべてのログを収集してメールで送信する「ワンクリック」ツールです。

また、アプリケーションのメインパスを大まかにたどることができるように、ログに記録する内容を適切に選択してください。

フレームワークとして、標準（log4net、log4java、log4c ++）を使用しました

すぐに使用できる優れたフレームワークがすでに存在する場合は、独自のロギングフレームワークを実装しないでください。車輪の再発明をするだけのほとんどの人。

Answer 3

一部の人々は、デバッガーをまったく使用せず、すべてをログに記録します。それは異なる哲学であり、自分で選択する必要があります。これらのような多くのアドバイスを見つけることができます。これらのアドバイスは言語に関連していないことに注意してください...

Coding Horror の男が、ロギングの問題と、特定の状況で不正なロギングが時間の浪費になる理由について興味深い投稿を受け取りました。

ロギングは、本番環境に残る可能性のあるものを追跡するためのものだと単純に信じています。デバッグは開発用です。デバッガーに耐えられないため、デバッグにログを使用する人もいるため、単純すぎる見方かもしれません。しかし、デバッガー モードは時間の無駄にもなり得ます。テスト ケースのようなものを使用する必要はありません。書き留めておらず、デバッグ セッション後に消えるからです。

だから私はこれについての私の意見だと思います：

• ログ フレームワーク ( log4ファミリ ツール)を使用して、開発および実稼働レベルで、開発および実稼働環境を通じて必要かつ有用なトレースをログに記録する
• 物事が制御不能になったときの特別な奇妙なケースのためのデバッグモード
• テスト ケースは重要であり、反回帰手法として使用される地獄のような迷宮のようなデバッグ セッションに費やす時間を節約できます。ほとんどの人はテスト ケースを使用しないことに注意してください。

コーディング ホラーは、すべてをログに記録する傾向に抵抗すると述べています。そうです、しかし、私はすでに、まったく逆のことをきれいな方法で（そしてデータベースを介して）実行するハッジアプリを見てきました...

Answer 4

複数のログレベルを持つようにログシステムをセットアップするだけです。私が書いたサービスでは、ほぼすべてのアクションのログ/監査があり、監査レベル1〜5が割り当てられ、数が多いほど、より多くの監査イベントが割り当てられます。

1. 非常に基本的なロギング: 開始、停止、および再開
2. 基本ロギング: 処理中 x ファイル数など
3. 標準ロギング：処理開始、処理終了など
4. 高度なロギング: 処理の各段階の開始と終了
5. すべて : 実行されるすべてのアクション

構成ファイルで監査レベルを設定して、その場で変更できるようにします。

Answer 5

Apache で使用されているものなど、既存のログ形式を使用すると、形式を分析するために使用できる多くのツールを利用できます。