logging - ロギング、いつ、何を？

Question

私は現在、海外に展開されるかなり大規模な多層アプリに取り組んでいます。展開後に倒れたり爆発したりしないことを願っていますが、これを100％確信することはできません. そのため、ログ ファイルをリクエストして、何が問題で、その理由を正確に把握できると便利です。

基本的に、タイトルが示すように、いつ、何をログに記録するか知りたいですか? アプリがダウンした場合に何が起こったのかを簡単に調べることができる包括的なログ ファイルを確保するために、これを知りたいです。

Answer 1

1 - 標準化された形式で単一のログを作成します。それが何であるかは大した問題ではありませんが、すべてのエントリに同じ基本フィールドがあることを確認してください。「printf」を呼び出すだけでは、おそらくうまくいきません（ System.err.println などを適宜置き換えてください）

2 - 少なくとも 1 つのフィールドを任意の文字列にすることができます...開発者は、そこに何が必要かをよく知っています。

3 - 各エントリに高解像度のタイムスタンプを含めます。あなたは最終的にそれを必要とするでしょう、私を信じてください.

4 - 可能であれば、エラーの発生元のファイルと行番号を含めてください。これは C では簡単ですが、Java では少し面倒です。しかし、後で、特に人々がエラー メッセージを含めてコードをカット アンド ペーストし始めたときに、非常に役立ちます。

5 - ログがコードのどのレベルでも使用できる場所にあることを確認します。

6 - 私はよく "Primary" と "Secondary" のエラー タグを使用してきました。ここで、"Primary" は "私は問題があることを検出した人です" を意味し、"Secondary" は "エラーを報告した関数を呼び出しました" を意味します。 "。これにより、問題の原因 (「プライマリ: ファイルが見つかりません」) を簡単に見つけて、エラーの意味を報告できます (「セカンダリ: キャリブレーション テーブルを読み込めません」)。

7 - エラーだけでなく非エラーもログに記録する機能を含めます。

私が見つけた最も難しい部分は、エラーが必ずしもエラーではない場合です。ファイルで関数を呼び出し、ファイルが存在しない場合、それはログに記録する必要があるエラーですか? 重大な障害である場合もあれば、予期されている場合もあります。関数の API 次第です。関数にエラーを返す方法がある場合は、通常、ログを記録せずにエラーを返すようにします。次に、そのエラーを報告する必要があるかどうか、またはそれが予想されるかどうかを決定するのは、上位レベルのコードの仕事です。

Answer 2

まず、ロギング フレームワークを用意してください。具体的な言語については触れていませんが、Apache log4j に基づくフレームワークであればどれでも安全な方法です。最も重要なことは、フレームワークがさまざまなレベルの冗長性 (デバッグ メッセージ、警告、エラー メッセージ) をサポートしていることです。実際にどのメッセージをどこに書き込むかについて、実行時にロガーを構成できます。ロギングを操作するために車輪を再発明しても意味がありません。

ソースにロギング フレームワークを実装します。少なくとも、アプリケーションで発生する可能性のある例外を記録し、「価値を追加」することを検討する必要があります。スタック トレースをログ ファイルに書き込むことは問題ありませんが、問題を診断するには十分ではありません。メソッド パラメータの値などを catch {} に記録することを検討してください。

より高いレベルでは、さまざまなレベルの冗長性を利用して、アプリケーションで何が起こっているかを記録できます。これは、リモート デバッガーをアタッチできない運用システムでのみエラーが発生している場合に特に役立ちます。 Y") メッセージがログに表示されます。

Answer 3

クライアントを介して送信されたログの助けを借りて、問題が展開された後にのみ調査できる大規模なミッションクリティカルなアプリケーションの場合、いつどこにログを記録するかについての良い感覚が時間とともに来るということを少しだけ追加したいと思います。アプリケーションは成熟します（成熟度は、アプリケーションが1つの場所で展開および使用されるのに費やす時間と、[さまざまなクライアント/場所での]さまざまな展開の数に直接関係します）。

Answer 4

私たちは、世界中で使用されている大規模な電話ベースのシステムを開発し、アプリケーションに独自のロギングシステムを長年使用してきました。デバッグのレベルは非常に重要であり、当社のアプリはデバッグが「エラーのみ」に設定された状態で出荷され、最も時間に敏感なものを除くすべてでファイルへのログが有効になっています。また、出力をデバッグトレースシステムに転送することもサポートしています（これはWindowsであるため、OutputDebugStringを呼び出すだけで、エンジニアはDBWIN32と呼ばれるデバッグキャッチャーにアクセスできます）。一部のクラスのバグでは、シリアル化された複数のアプリからの出力を表示できる必要があるため、これは重要です。この手法を適用することで、いくつかの非常にトリッキーなマルチアプリインタラクションのバグを解決しました。このシナリオでは、アプリは通常、人間が読める形式のタグを出力に追加して、どの行がどのアプリからのものかを判断できるようにします。

通常、使用するレベルは次のとおりです。オフ、エラーのみ、基本、詳細、「詳細」（詳細は、投票結果、ユーザー操作、メッセージの内容など、作成者が重要と考える複数のことを意味するプレースホルダーです）。

ああ、アプリがログファイルに最初に書き込むのは、バージョンリソースを提供するヘッダーなので、処理しているビルドを確認できます。ユーザーやローカルエンジニアに知らせてはいけません:-)

Answer 5

AOPは、邪魔にならないロギングに非常に役立ちます。たとえば、AOPを使用して、各メソッドに実際にログステートメントを追加しなくても、すべてのメソッド呼び出しのパラメーター値と戻り値をログに記録できます。

これを行う方法の具体的な詳細は、明らかにターゲット言語とプラットフォーム（指定しなかったもの）によって異なります。このようなロガーをJavaSpringベースのアプリケーションに追加する方法の例については、ここを参照してください。

Answer 6

パフォーマンスに多額の料金を支払う必要がない限り、ロギングは重要です。

私の経験では、ログに記録したい最も重要なことは、警告、おっと、サニティ チェックの失敗、雨の日のシナリオなどです。 print "We should not get here" など。これらは、テスト中には表示されず、もちろんキャプチャされない展開中にポップアップし始める傾向があります。

ログを記録し、結果をリモートで読み取る場合は、正確なタイムスタンプ、場所、およびある種のセッション ID を取得してください (複数のインスタンスが同時に実行され、ログ ファイルに書き込まれている場合)。どのメッセージが 1 回の実行の一部であるかを判断するのが簡単であるほど、優れています。

エラーのレベルとタイプも重要です。複数の場所から同じメッセージを書いていないことを確認するために検索を行うことも重要です。そうしないと、追跡が困難になります。

最後に、ユーザーが Mac OS X を実行している場合は、エラーのログ記録に細心の注意を払ってください。何らかの奇妙な理由で、Leopard であっても、デフォルトのログ記録メカニズムは処理にコストがかかり、大量の CPU を占有する可能性があります。