1.背景
日常の開発では、通常、問題のデバッグとチェックに便利なように、多くのINFOレベルのログが出力されます。
訪問数が増えると、注意しないと、1日のログファイルのサイズが特定のしきい値（5Gなど）よりも大きくなります。したがって、ログサイズを最適化するためのアラームが表示され、ログサイズが一定期間内に最適化されていない場合は、上司に報告してください。、おっと...
ログが大きすぎると、ログファイルの取得、データ収集、ディスククリーニングなど、一部の操作やメンテナンス操作でマシンのパフォーマンスが低下しやすくなります。
では、ログスリミングの一般的なアイデアは何ですか？この記事は、私の見解について話す特定のケースに基づいています。
2.日記の痩身方法
2.1必要なログのみを印刷する
テストの便宜のために、多くのINFOレベルのログが一時的に印刷される場合があります。このようなログの場合、プロジェクトが稼働する前に、不要なログを削除するか、DEBUGレベルに調整できます。
ただし、シナリオによっては、一部のログをDEBUGまたはINFOとして印刷できます。INFOレベルでの印刷はスペースを占有し、オンラインで問題をチェックする場合はDEBUGレベルでの印刷を使用する必要があります。どうすればよいですか。
ログツールクラスを変換して、コンテキスト転送で特定のスイッチをサポートでき（通常の呼び出しにはこのスイッチはありませんが、会社のトレーサーまたはRPCコンテキストを通過します）、DEBUGログを一時的にINFOレベルにアップグレードできます。擬似コードは次のとおりです。
if(log.isDebugEnable()){
log.debug(xxx);
}else if(TracerUtils.openDebug2Info()){
log.info("【debug2info】"+xxx);
}
このように、INFOログとして印刷するかどうかについて混乱している一部のログは、DEBUGレベルとして印刷でき、問題がチェックされると自動的にINFOログにアップグレードされます。誤解を避けるために、DEBUGブーストINFOログと通常のINFOログを区別し、[debug2info]のようなログプレフィックスを追加します。
もちろん、他の凶悪な操作を行うこともできます。これは単なる例です。自分で推測してください。
2.2複合印刷
マージできるいくつかのログは、マージの対象と見なすことができます。
同じ方法の前後にINFOログが出力される場合：
INFO[64ビットtraceId]実行前のXXXServiceサイズ=10INFO[64ビットtraceId]実行後のXXXServiceサイズ=4
1つに組み合わせることができます：
INFO[64ビットtraceId]XXXServiceサイズ=10実行前、サイズ=4実行後
2.3簡略化と省略と圧縮
某个日志非常有必要，但是打印的对象有些大，如果可以满足问题排查需求的情况下，我们可以：
（1）选择只打印其 ID
（2）创建一个只保留关键字段的日志专用对象，转化为日志专用对象，再打印。
（3）可以用缩写，如 write 简化为 w, read 简化为 r, execute 简化为e 等；比如 pipeline 中有 20个核心 bean ，打印日志时可以使用不同的编号替代 bean 全称，如 S1,S2 ，虽然没那么直观，但既可以查问题，又降低了日志量。
三、优化案例
3.1 场景描述
一个业务场景涉及很多 bean， 为了复用一些通用逻辑，这些 bean 都继承自某个抽象类。 在抽象类中，定义了执行 bean 前后的一些通用逻辑，如执行前后打印当前 pipeline 中 item 的数量。 最后一个 bean 执行完结果转换后需要打印出结果。
3.2 优化分析
3.2.1 只打印必要日志
（1）由于当前 bean 执行前 相当于前一个 bean 执行后，因此只打印执行后的日志就可以，执行前的INFO 日志可以删除或者改为 DEBUG （只打印必要日志）
（2）通常问题只出现在执行前后 size 不一致的情况下，因此执行后打印日志前可以加个判断，如果执行前后 size 相同则不打印。（只打印必要日志） 伪代码如下：
if(sizeBefore != sizeAfter){
log.info("service:{}, 前size:{},后size:{}", getName(),sizeBefore, sizeAfter)
}
这招效果很明显，因为大多数 bean 的执行前后 size 是相同的，就不会打印这条日志。 而假设之前有 20 个，这条日志就需要打印 20次，改进后可能只需要打印 2-3 次。
3.2.2 日志合并
（2）为了方便查问题还需要打印执行前的 size ，那么将执行前的 size 记录在内存中，打印执行后日志时多打印出执行前的 size。（合并打印） 伪代码如下：
log.info("service:{}, 执行前size:{}", getName(),sizeBefore)
log.info("service:{}, 执行后size:{}", getName(),sizeBefore, sizeAfter)
合并后
log.info("service:{}, 前size:{},后size:{}", getName(),sizeBefore, sizeAfter)
3.2.3 日志精简
对于最终结果，将结果对象（如 XXDTO）转化为只包括关键信息，如 id, title 的日志对象（XXSimpleLogDTO），转化为日志对象后再打印。
log.info("resultId:{}",result.getId());
或者
log.info("result:{}",toSimpleLog(result));
3.3 效果评估
ログは1日に約5GBを生成し、その約80％が印刷前後のサイズであり、約10％が印刷の最終結果であり、他にもいくつかのログがあります。上記の方法が最適化された後、1日のログ量は1G未満になります。
トラブルシューティングのニーズを満たすこととログの間引きを実現することの間にはトレードオフがあります。
4.まとめ
ログの間引きにはトレードオフが必要であり、問題のトラブルシューティングに必要なログを可能な限り薄くします。
不要なログを削除し、ログをマージし、ログを単純化することで最適化できます。
また、いくつかのトリッキーな操作を実行し、オンラインDEBUGをサポートして、問題のチェックを支援するためにINFOを一時的に増やすことができます（もちろん、arthasも使用できます）。
他にどのような良い日記のヒントがありますか？記事の最後にコメントして、私と連絡してください。
作成するのは簡単ではありません。この記事があなたに役立つ場合は、いいね、お気に入り、フォローしてください。あなたのサポートと励ましが私の作成の最大の動機です。