Java ロギングを正しく使用する方法

ログについては、比較的簡単だと誰もが思っていますが、関連する依存関係パッケージを導入するだけで、あとはプロジェクトに必要な情報の出力を「楽しむ」だけです。しかし、多くの場合、物事が単純であればあるほど、私たちはそれらを無視しやすくなり、発生するはずのないバグの発生につながります。そこでログの正しい利用姿勢について学んでいきましょう。

#テキスト

ログ仕様

命名

最初は、ログ ファイルの命名です。名前をよく理解し、理解するように努めてください。統一された命名規則を使用する必要があり、そうしないと、「汚くて乱雑な」ログ ファイルが問題のトラブルシューティングにおける全員の効率に影響を及ぼします。名前から、ログ ファイルがどのプロジェクトに属し、どのようなタイプで、どのような機能があるのか​​が明確にわかるように、「projectName_logName_logType.log」という名前を付けることをお勧めします。たとえば、MessageServer プロジェクトでは、Rabbitmq コンシューマの監視に関連するログ ファイル名を「messageserver_rabbitmqconsumer_monitor.log」として定義できます。

時間の節約

ログの保存期間については、通常のログ ファイルは 15 日間保存することをお勧めしますが、より重要な場合は、状況に応じて延長できます。 、それぞれのサーバーのディスク容量とログ ファイルのサイズを参照して、最適な選択を行ってください。

ログ レベル

一般的なログ レベルは次のとおりです。

DEBUG レベル: デバッガ関連の情報を記録します。 INFO レベル: プログラムの通常の動作に関する意味のある情報を記録します。 WARN レベル: エラーを引き起こす可能性のある情報を記録します。エラー レベル: 現在のプログラム エラーに関する情報を記録し、注意と処理が必要です。致命的レベル: 重大なエラーが発生し、プログラムの実行が中断されることを示します。

プロジェクトでは、ERROR、WARN、INFO、DEBUG の 4 つのレベルを使用することをお勧めします。

正しい姿勢

1.ログレベルを事前に判断する

//条件判断if(logger.isDebugEnabled){
    logger.debug("server info , id : " + id + ", user : " + user);
}//使用占位符logger.debug("server info , id : {}, user : {}",id,user);

DEBUG レベルや INFO レベルのログはプログラム内に比較的頻繁に存在しますが、プロジェクトが大きくなりログの数が増えた場合、より効率的にプログラムを実行するためには条件やプレースホルダで判断してログを出力する必要があります。なぜ？プロジェクトで設定されたログ レベルが WARN の場合、次のログ出力ステートメント「logger.debug("server info, id: "id", user: "user);」では、ログは出力されませんが、 , 文字列のスプライシング操作が実行されますが、ここではユーザーがインスタンス オブジェクトであるため、toString メソッドも実行され、多くのシステム リソースが無駄になります。

2. 冗長なログ出力を避ける

弊社の運用環境では、DEBUG ログの出力は一般的に禁止されており、出力頻度が非常に高いため、通常に実行中のプログラムに深刻なダメージを与える可能性があります。影響、私たちは最近のプロジェクトでも同様の状況に遭遇しました。

次に、加法性属性の使用方法を学習します

<logger name="xx" additivity="true">

ここで true に設定されている場合、これがデフォルトの状況です。この時点で、現在のロガーは親ロガーのアペンダーを継承します。 . 端的に言えば、現在の ログ出力は現在のログファイルに出力されるだけでなく、親ファイルにも出力されます。したがって、一般に、繰り返しの印刷を避けるために、このパラメータを false に設定して、不必要な出力を減らします。

3. ログレコード情報が完全であることを確認してください

コードでは、ログレコードの内容に例外スタックを含める必要があります。「XX エラー」などの単純なログを勝手に出力しないでください。これは非常に重要です。エラーのデバッグは役に立ちません。したがって、例外を記録するときは、

logger.error("rabbitmq consumer error,cause : "+e.getMessage(),e);

などのスタック情報を取得する必要があります。オブジェクト インスタンスを出力するときは、オブジェクトが toString メソッドをオーバーライドしていることを確認する必要があります。そうしないと、その hashCode 値のみが出力されます。

4. ロガー変数を静的として定義します

private static final Logger logger = LoggerFactory.getLogger(XX.class);

オブジェクトが毎回再作成されることを避けるために、オブジェクトが 1 つの Logger オブジェクトのみを使用するようにしてください。そうしないと、OOM が発生する可能性があります。

5. ログ レベルを正しく使用する

try{    //..}catch(xx){
    logger.info(..);
}

この方法では、元々エラーだったすべての情報が INFO ログ ファイルに出力され、何も知らない同僚は依然としてエラー ログを見つめることになります。 . で問題が見つからない場合、作業効率に影響しますよね?

6. slf4j logback の組み合わせを使用することをお勧めします

logback ライブラリ自体はすでに slf4j インターフェイスを実装していますなので、冗長アダプターを導入する必要がなく、ログバックの方がメリットが多いため、新規プロジェクトではこの組み合わせを使用することをお勧めします。もう 1 つ注意すべき点は、slf4j を導入した後、実際に使用されるログ ライブラリが当社によって導入されたものか、それともサードパーティの依存関係パッケージによってもたらされたログ ライブラリを使用する可能性があるかに注意する必要があるということです。無効。

7. ログ集約分析

ログ集約は、異なるサーバー間のログを統合して分析・処理することができ、現在では ELK テクノロジー スタックや EFG (fluentd elasticsearch grafana) などが比較的成熟しています。オープンソースのソリューション。

ELK を例に挙げると、サーバー上の logstash を介してアプリケーションによって出力されたログ ファイルを直接読み取ることができます。また、プロジェクト内のログ構成ファイルに関連するソケット情報を構成して出力することもできます。このとき、ログ情報はlogstashに直接出力されます。その後、ストレージと kibana 表示のために elasticsearch に渡されます。

関連チュートリアル: Java ビデオ チュートリアル

以上がJava ロギングを正しく使用する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。