プログラマーのログの品質を向上させる 5 つの方法

プログラマのログの品質を向上させる 5 つの方法
最近、Scribe や Logstash などのオープンソース プロジェクト、Splunk などのプリペイド ツール、SumoLogic などのホスティング サービスなど、プログラマがログを理解するのに役立つさまざまな新しいツールが登場しました。ペーパートレイル。これらのツールに共通しているのは、ログ データをクリーンアップし、大量のログからより価値のあるファイルを抽出することです。
ログの品質を向上させる 5 つのヒント
しかし、これらのツールでは役に立たないことが 1 つあります。なぜなら、これらのツールは実際に入力したログ データに完全に依存しており、データの品質と量を確保する方法はユーザーが行う必要があるからです。 。したがって、重要な瞬間に、部分的なログまたは欠落したログに基づいてコードをデバッグする必要がある場合、作業が困難になる可能性があります。
この状況の発生を減らすために、ログを記録するときに留意すべき 5 つの提案を以下に示します。
1. こんにちは、私の (スレッド) 名は です
Ringo と同様に、スレッド名の属性は Java です。過小評価されている手法。その理由は、スレッド名はほとんどが説明的なものだからです。しかし、ここでも問題が発生します。人自身と同じように、名前を付けるとき、人は通常、名前に何らかの意味を与えます。マルチスレッド ログでは、スレッド名も重要な役割を果たします。通常、ほとんどのロギング フレームワークは、現在呼び出されているスレッドの名前を記録します。残念なことに、http-nio-8080-exec-3 のような名前は、スレッド プールまたはコンテナによって単に割り当てられているだけです。
何らかの理由で、私たちはこの誤解を何度も聞いてきました - スレッド名は不変です。対照的に、ログではスレッド名が基本的な役割を果たすため、正しく使用する必要があります。たとえば、サーブレットの名前、タスク関連、またはユーザー ID やメッセージ ID などの動的コンテキストなどの特定のコンテキストと組み合わせます。
この場合、コードインターフェイスは次のようになります:
Thread.currentThread().setName(ProcessTask.class.getName() + “: “+ message.getID);
より高度なバージョンがスレッドにロードされます現在のスレッドのローカル変数を使用してログ アペンダを構成し、ログ エントリに自動的に追加します。
これは、複数のスレッドがサーバー ログに書き込んでいるが、単一のスレッドに注目する必要がある場合に便利です。分散/SOA 環境で実行している場合は、その独自の利点を確認することもできます。
2. 分散識別子
SOA またはメッセージ駆動型アーキテクチャでは、タスクの実行は複数のマシンにまたがる可能性があります。このような環境で障害が発生した場合、関連するマシンとその状態を接続することが状況を把握する鍵となります。ほとんどのログ アナライザーは、これらのログ メッセージをグループ化して、一意の識別子を指定すると、実際のログ メッセージの一部にできるようにします。
設計の観点から見ると、これは、システムの入力から操作の完了まで、各受信操作には独自の一意の ID が必要であることを意味します。ユーザー ID などの永続的な識別子は、適切なコンテナーではない可能性があることに注意してください。ログ ファイルに記録するプロセス中に、ユーザーが複数のアクションを実行する可能性があるため、特定のフローを分離することがより困難になります。 UUID は良い選択かもしれません。その値は、実際のスレッド名にロードすることも、TLS スレッドのローカル ストレージとしてロードすることもできます。
3. テキスト + ドライブを使用しない、ログ + ループを使用しない
多くの場合、コードがタイトなループで実行され、対応するログ操作が実行されていることがわかります。基本的な前提は、コードを実行できる回数は限られているということです。
おそらくとてもうまくいきます。ただし、コードが予期しない入力を受け取った場合、ループが中断されない可能性があります。この場合、単に無限ループを扱っているだけではなく (それでも十分に悪いことではありますが)、無限量のデータをディスクまたはネットワークに書き込むコードを扱っていることになります。
スタンドアロン シナリオでは、サーバーがクラッシュする可能性がありますが、分散シナリオではクラスター全体が影響を受けます。したがって、可能であれば、タイトなループにログインしないでください。これは、エラーをキャッチする場合に特に当てはまります。
次の例では、while ループで例外を記録します。
void read() {
while (hasNext()) {
try {
readData();
} catch {Exception e) {
// これはお勧めしません。
logger.error(“データの読み取りエラー”, e);
}
}
}
readData が例外をスローし、hasNext が true を返した場合、無制限のログ データがここに書き込まれます。これを修正する方法は、これがログに記録されないようにすることです。 ) {
if (例外スローン < THRESHOLD) {
logger.error("データ読み取りエラー", e);
例外スローン++;
// これで、エラーがシステムを停止させることはなくなりました。 }
}
もう 1 つの方法は、ループからロギングを削除し、最初と最後の例外オブジェクトを保存して、別の場所に記録することです。
4. 捕らえられなかったハンドラー
Westeros には最後の防御壁があり、Thread.uncaughtExceptionHandler があります。したがって、できるだけそれらを使用するようにしてください。これらのハンドラーがインストールされていないと、例外がスローされたときに貴重なコンテキストがほとんど得られず、例外が終了する前にどこにログを記録したかを制御できません。
(終了した) スレッド内の変数にアクセスする方法がないように見える、キャッチされなかった例外ハンドラーでも、実際のスレッド オブジェクトへの参照を取得できることに注意してください。手順 1 に固執した場合でも、ログに記録する意味のある thread.getName() 値を取得できます。
5. 外部呼び出しをキャプチャする
外部 API が呼び出されるたびに、JVM 例外が発生する可能性が大幅に増加します。これには、Web サービス、HTTP、DB、ファイル システム、オペレーティング システム、およびその他の JNI 呼び出しが含まれます。いつ爆発する可能性があるため、すべての電話を真剣に受け止めてください。「同じ時点で発生する可能性が非常に高い」です。
ほとんどの場合、外部 API の失敗の原因は予期しない入力であり、それをログに記録することがコードを修正する鍵となります。
この時点で、エラーをログに記録せずに例外をスローすることを選択できます。この場合、呼び出しの関連パラメータを収集し、それらを解析して例外エラー情報を生成するだけです。
例外がより高いレベルのスタック呼び出しでキャッチされ、ログに記録されることを確認してください。
LAMP Brothers オリジナルの PHP ビデオチュートリアル CD/「Essential PHP inDetails」を無料で入手 詳細は、公式 Web サイトのカスタマーサービスまでお問い合わせください:
http://www.lampbrother.net
【Brothers IT Education】PHP を学び、 Linux、HTML5、UI、Android、その他のビデオ チュートリアル (コースウェア + ノート + ビデオ)!
ネットワークディスクチュートリアルのダウンロード: http://pan.baidu.com/s/1mg8ANMg

以上、プログラマのログの質を高める5つの方法を内容面も含めて紹介しましたので、PHPチュートリアルに興味のある友人の参考になれば幸いです。