Javaログ姿勢を正しく印刷!
ログを打つ正しい方法
いつログを打つべきですか
1.問題が発生した場合、debug機能で問題を特定するしかありません.ログを打つことを考えるべきです.良いシステムは、ログを通じて問題を決めることができます.
2.if...elseまたはswitchのようなブランチに遭遇した場合、ブランチの最初の行にログを印刷して、どのブランチに入ったかを決定します.
3.常に機能を核心として開発を行い、コードを提出する前に、ログを通じてプロセス全体を見ることができることを確定する必要があります.
きほんけいしき
パラメータ化された情報を使用する必要があります.
Debugログでは、debugレベルかどうかを判断してから使用する必要があります.
文字列の結合を行わないでください.そうすれば、多くのStringオブジェクトが発生し、スペースが消費され、パフォーマンスに影響します.反例:
[]を使用したパラメータ変数の分離
パラメータ変数がある場合は、次のように書くべきです.
このようなフォーマットの書き方は、可読性が高く、問題の調査に役立ちます.
異なるレベルでの使用
ERROR
基本概念
プログラムの正常な動作、現在の要求の正常な動作に影響する異常:
1.プロファイルのオープンに失敗しました
2.すべてのサードパーティドッキングの異常(サードパーティ返却エラーコードを含む)
3.SQLExceptionと業務異常以外のすべての異常(RuntimeExceptionとException)を含む、機能に影響を与えるすべての異常
発生すべきでない状況:
1.たとえばAzureを使用して画像を転送しますが、Azureは応答しません.
Throwable情報がある場合は、完了したスタック情報を記録する必要があります.
説明
1.異常放出操作が行われた場合、errorログを記録せずに、最終処理者が処理します.
反例:
WARN
基本概念
プログラムに影響を与えないが、現在の要求が正常に実行されている異常は発生しない.
1.フォールトトレランスメカニズムがある場合に発生するエラー
2.プロファイルが見つかりませんが、自動的にプロファイルを作成できます.
臨界値に近づくと、次のようになります.
1.キャッシュプール占有率が警告ラインに達する
次のようなビジネス・例外の記録.
1.インタフェースからビジネス例外が放出された場合、この例外を記録する必要があります.
INFO
基本概念
システム運転情報
1.サービス方法におけるシステム/業務状態の変更
2.主な論理におけるステップ分け
外部インタフェース部
1.クライアント要求パラメータ(REST/WS)
2.サードパーティの呼び出し時の呼び出しパラメータと呼び出し結果
説明
1.すべてのサービスが出入口打点記録を行うわけではないが、単一で単純なサービスでは意味がない(jobを除き、jobは開始と終了を記録する必要がある).
反例:
2.複雑な業務ロジックについては、電子商取引システムにおける注文ロジックやOrderAction操作(業務状態変更)などのログの打点、埋め込み記録が必要である.
3.システム全体で提供されたインタフェース(REST/WS)に対して、infoを使用してインパラメータを記録する
4.すべてのサービスがSOAアーキテクチャである場合、外部インタフェースプロバイダと見なすことができる場合は、パラメータを記録する必要があります.
5.他のサードパーティ・サービスを呼び出す場合、すべてのパラメータとパラメータは記録する必要があります(サードパーティ・モジュールで発生した問題を遡るのは難しいため)
DEBUG
基本概念
1.知りたい情報はすべて記入できる(ただし、勝手に書いてもいいわけではないが、debug情報には意味があり、関連パラメータがあることが望ましい)
2.生産環境はDEBUG情報を閉じる必要がある
3.生産状況でDEBUGをオンにする必要がある場合は、スイッチを使用して管理する必要があり、常にオンにすることはできません.
説明
コードに次のコードがある場合は、最適化できます.
最適化されたコード:
TRACE
基本概念
特に詳細なシステム運転完了情報は、業務コードでは使用しないでください.(特別な意図がない限り、DEBUGレベルで置き換えてください)
仕様例の説明
微信公衆番号から転載:Java学習者コミュニティ
いつログを打つべきですか
1.問題が発生した場合、debug機能で問題を特定するしかありません.ログを打つことを考えるべきです.良いシステムは、ログを通じて問題を決めることができます.
2.if...elseまたはswitchのようなブランチに遭遇した場合、ブランチの最初の行にログを印刷して、どのブランチに入ったかを決定します.
3.常に機能を核心として開発を行い、コードを提出する前に、ログを通じてプロセス全体を見ることができることを確定する必要があります.
きほんけいしき
パラメータ化された情報を使用する必要があります.
logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);
Debugログでは、debugレベルかどうかを判断してから使用する必要があります.
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " +id + " symbol: " + symbol);
}
文字列の結合を行わないでください.そうすれば、多くのStringオブジェクトが発生し、スペースが消費され、パフォーマンスに影響します.反例:
logger.debug("Processing trade with id: " + id + " symbol: " + symbol);
[]を使用したパラメータ変数の分離
パラメータ変数がある場合は、次のように書くべきです.
logger.debug("Processing trade with id:[{}] and symbol : [{}] ", id, symbol);
このようなフォーマットの書き方は、可読性が高く、問題の調査に役立ちます.
異なるレベルでの使用
ERROR
基本概念
プログラムの正常な動作、現在の要求の正常な動作に影響する異常:
1.プロファイルのオープンに失敗しました
2.すべてのサードパーティドッキングの異常(サードパーティ返却エラーコードを含む)
3.SQLExceptionと業務異常以外のすべての異常(RuntimeExceptionとException)を含む、機能に影響を与えるすべての異常
発生すべきでない状況:
1.たとえばAzureを使用して画像を転送しますが、Azureは応答しません.
Throwable情報がある場合は、完了したスタック情報を記録する必要があります.
log.error(" [{}] ",userName,e);
説明
1.異常放出操作が行われた場合、errorログを記録せずに、最終処理者が処理します.
反例:
try{
....}catch(Exception ex){
String errorMessage=String.format("Error while reading information of user [%s]",userName);
logger.error(errorMessage,ex);
throw new UserServiceException(errorMessage,ex);
}
WARN
基本概念
プログラムに影響を与えないが、現在の要求が正常に実行されている異常は発生しない.
1.フォールトトレランスメカニズムがある場合に発生するエラー
2.プロファイルが見つかりませんが、自動的にプロファイルを作成できます.
臨界値に近づくと、次のようになります.
1.キャッシュプール占有率が警告ラインに達する
次のようなビジネス・例外の記録.
1.インタフェースからビジネス例外が放出された場合、この例外を記録する必要があります.
INFO
基本概念
システム運転情報
1.サービス方法におけるシステム/業務状態の変更
2.主な論理におけるステップ分け
外部インタフェース部
1.クライアント要求パラメータ(REST/WS)
2.サードパーティの呼び出し時の呼び出しパラメータと呼び出し結果
説明
1.すべてのサービスが出入口打点記録を行うわけではないが、単一で単純なサービスでは意味がない(jobを除き、jobは開始と終了を記録する必要がある).
反例:
ublic List listByBaseType(Integer baseTypeId) {
log.info(" ");
BaseExample ex=new BaseExample();
BaseExample.Criteria ctr = ex.createCriteria();
ctr.andIsDeleteEqualTo(IsDelete.USE.getValue());
Optionals.doIfPresent(baseTypeId, ctr::andBaseTypeIdEqualTo);
log.info(" ");
return baseRepository.selectByExample(ex);
}
2.複雑な業務ロジックについては、電子商取引システムにおける注文ロジックやOrderAction操作(業務状態変更)などのログの打点、埋め込み記録が必要である.
3.システム全体で提供されたインタフェース(REST/WS)に対して、infoを使用してインパラメータを記録する
4.すべてのサービスがSOAアーキテクチャである場合、外部インタフェースプロバイダと見なすことができる場合は、パラメータを記録する必要があります.
5.他のサードパーティ・サービスを呼び出す場合、すべてのパラメータとパラメータは記録する必要があります(サードパーティ・モジュールで発生した問題を遡るのは難しいため)
DEBUG
基本概念
1.知りたい情報はすべて記入できる(ただし、勝手に書いてもいいわけではないが、debug情報には意味があり、関連パラメータがあることが望ましい)
2.生産環境はDEBUG情報を閉じる必要がある
3.生産状況でDEBUGをオンにする必要がある場合は、スイッチを使用して管理する必要があり、常にオンにすることはできません.
説明
コードに次のコードがある場合は、最適化できます.
//1. //2. //3.
最適化されたコード:
logger.debug(" [{}] [{}] ",employee,year);
logger.debug(" [{}] [{}] [{}]",employee,year,basicSalary);
logger.debug(" [{}] [{}] [{}] ",employee,year,month);
logger.debug(" [{}][{}] [{}] / / [{}]/[{}]/[{}]",employee,year,month,annualLeaveDays,sickLeaveDays,noPayLeaveDays);
logger.debug(" [{}][{}] [{}] ",employee,year,month);
logger.debug(" [{}] [{}] [{}] [{}]",employee,year,month,actualSalary);
TRACE
基本概念
特に詳細なシステム運転完了情報は、業務コードでは使用しないでください.(特別な意図がない限り、DEBUGレベルで置き換えてください)
仕様例の説明
@Override@Transactionalpublic
void createUserAndBindMobile(@NotBlank String mobile, @NotNull User user) throws CreateConflictException{
boolean debug = log.isDebugEnabled();
if(debug){
log.debug(" . args[mobile=[{}],user=[{}]]", mobile, LogObjects.toString(user));
}
try {
user.setCreateTime(new Date());
user.setUpdateTime(new Date());
userRepository.insertSelective(user);
if(debug){
log.debug(" . insertedUser[{}]",LogObjects.toString(user));
}
UserMobileRelationship relationship = new UserMobileRelationship();
relationship.setMobile(mobile);
relationship.setOpenId(user.getOpenId());
relationship.setCreateTime(new Date());
relationship.setUpdateTime(new Date());
userMobileRelationshipRepository.insertOnDuplicateKey(relationship);
if(debug){
log.debug(" . relationship=[{}]",LogObjects.toString(relationship));
}
log.info(" . userId=[{}],openId=[{}],mobile=[{}]",user.getId(),user.getOpenId(),mobile);
// , }
catch(DuplicateKeyException e){
log.info(" , . openId=[{}],mobile=[{}]",user.getOpenId(),mobile);
throw new CreateConflictException(" , openid=[%s]",user.getOpenId());
}
微信公衆番号から転載:Java学習者コミュニティ