私は開発者として、書き込みのバグに加えて、伐採によるバグに対処することができるはず、我々はすべて知っていると信じています。このように、質問のラインアウトは、一部の人は誰かが検出すると決意は、それがいかに重要であるか外に自分のバグに従事する方法を知って、私たちは、目に見える......自分の仕事を続けることができ、私たちを必要とし、解決するために私たちに来ます。
ねえ、ジョークは、トピックを導入しました。log4jの、logbackと上のように：私は多くの人々がプロジェクトのログ管理ツールで使用していると考えています。、彼は3月7日21かかわらず、コンフィギュレーション・ファイルを見つけて、それがより信頼性の高い監視するプロジェクトのlog4jを使用するために、良い、Mavenの適切なパッケージをインポートし、インターネット：しかし、私はそのログを構成してプロジェクトに追加しているどのように多くの人がわかりません通常の出力は、[OK]を、書き込みのバグが継続近い設定ファイルへ行くか、ログファイル内の項目を配置しようが、構成の少し知識を持っている設定ファイルのために、とにかく、ラインで使用することができます。
実際には、これはすべての後に、唯一のCVプログラマには、将来のキャリアの見通しではありません、非常に良い習慣です。強い弟は今日、プロジェクトの簡単な前に彼の過去からの実際のケースに基づいて、我々は、オンラインプロジェクト、ロギング設定の問題のいくつか、そしてアプローチにについて話しています。
まず、プロジェクト、log4j2.xmlログファイルの内容のコンフィギュレーションの開始上に線を投影します：
<?xml version="1.0" encoding="UTF-8"?>
<configuration status="WARN" monitorInterval="30">
<Properties>
<Property name="fileName">./logs/xxx</Property>
</Properties>
<!--先定义所有的appender-->
<appenders>
<!--这个输出控制台的配置-->
<console name="Console" target="SYSTEM_OUT">
<!--输出日志的格式-->
<PatternLayout pattern="[xxx] [%d{yyyy-MM-dd HH:mm:ss,SSS}] [%t] [%p] %c{1}:%L - %m%n"/>
</console>
<!-- 这个会打印出所有的info及以下级别的信息，每次大小超过size，则这size大小的日志会自动存入按年份-月份建立的文件夹下面并进行压缩，作为存档-->
<RollingFile name="RollingFileDebug" fileName="${fileName}/debug.log"
filePattern="${fileName}/$${date:yyyy-MM}/debug-%d{yyyy-MM-dd}-%i.log">
<!--控制台只输出level及以上级别的信息（onMatch），其他的直接拒绝（onMismatch）-->
<ThresholdFilter level="debug" onMatch="ACCEPT" onMismatch="DENY"/>
<PatternLayout pattern="[xxx] [%d{yyyy-MM-dd HH:mm:ss,SSS}] [%t] [%p] %c{1}:%L - %m%n"/>
<Policies>
<TimeBasedTriggeringPolicy/>
<SizeBasedTriggeringPolicy size="10 MB"/>
</Policies>
<DefaultRolloverStrategy/>
</RollingFile>
<RollingFile name="RollingFileInfo" fileName="${fileName}/info.log"
filePattern="${fileName}/$${date:yyyy-MM}/info-%d{yyyy-MM-dd}-%i.log">
……//内容类似上面的RollingFileDebug
</RollingFile>
<RollingFile …… </RollingFile>
</appenders>
<!--然后定义logger，只有定义了logger并引入的appender，appender才会生效-->
<loggers>
<!--过滤掉spring和mybatis的一些无用的DEBUG信息-->
<logger name="org.springframework" level="INFO"></logger>
<logger name="org.mybatis" level="DEBUG"></logger>
<root level="debug">
<appender-ref ref="Console"/>
<appender-ref ref="RollingFileDebug"/>
……
</root>
</loggers>
</configuration>プロジェクトは、タイマー機能を持って、その後、大分、サードパーティのコンテンツインターフェイスごとに魚の数、クエリデータ、およびデータストレージを処理しています。
ログの設定：
<loggers>
<!--过滤掉spring和mybatis的一些无用的DEBUG信息-->
<logger name="org.springframework" level="INFO"></logger>
<logger name="org.mybatis" level="DEBUG"></logger>
<root level="debug">
<appender-ref ref="Console"/>
<appender-ref ref="RollingFileDebug"/>
……
</root>
</loggers>図から分かるように、ログコンソール出力するだけでなく、ログ出力や梱包の異なるレベル。このようなログファイルのディレクトリの最終アウト：
我々は改善の必要性を感じていないところプロジェクトの特性に合わせて、私は知らないのですか？
尾は、問題を見つけ、あなたはリアルタイムのログ出力を見ることができますCONSOLE.LOG -f：それは通常の出力ログファイルは、オンライン直接質問コマンドのノックアウトことが判明したプロジェクトのオンライン時間のほんの期間では、と何も間違っています。しかし、また、自動日次ログファイルのアーカイブ、保持、ログ履歴は、すべてがとても合理的で快適であるようです。
しかし、操作の期間のプロジェクトの後、徐々に問題を強調。ある日、強い弟は、ディスクが十分でないときに、同じマシンをデプロイするために、他のプロジェクトで見つかりましたか？？？奇数奇妙は、このマシンはそれのためのスペースがないか、いくつかのプロジェクトを入れていなかった、ファイルは大容量のディスクスペースを占有しているかを確認するにはヒットのコマンドを実行します。
find . -type f -size +800M -print0 | xargs -0 du -h | sort -nr一定期間後にラインアイテムを見つけ、にconsole.logログファイルは実際にはあまりある30以上のGに達しました。無意識のうちに、それだけで無法ポイントに独自の拡張プロジェクトのコンソール出力ログ。メインログ出力外部にデータ出力インターフェースの内容で、サードパーティ製の外観を得ることに加えて、SQL文を印刷しています。このプロジェクトは、ライン上で安定しているので、それは非常に単純なアプローチは、あるので、実際にSQL文菅ブーカーンの出力はほとんど影響を及ぼしません。だから、最初のログ出力レベルは、印刷のSQLステートメントを減らし、INFOレベルに変更されました：
<loggers>
<!--过滤掉spring和mybatis的一些无用的DEBUG信息-->
<logger name="org.springframework" level="INFO"></logger>
<logger name="org.mybatis" level="INFO"></logger>
<root level="INFO">
<appender-ref ref="Console"/>
<appender-ref ref="RollingFileDebug"/>
<appender-ref ref="RollingFileInfo"/>
<appender-ref ref="RollingFileWarn"/>
<appender-ref ref="RollingFileError"/>
</root>
</loggers>しかし、長い前に変更ログ出力レベルが、しかし理由は、サードパーティのプロジェクトのタイマーは、ログ出力インタフェースは依然として非常に大きい呼び出し、およびにconsole.logファイルは自動的にアーカイブされていない、ということが見つからない、ファイルが猛烈にとどまります拡大の毎日率は、ディスクから出て実行されます。
言うまでもない一度に貪欲なもの、今日のあなたは、この蛇を殺したい方法はありません。
<loggers>
<!--过滤掉spring和mybatis的一些无用的DEBUG信息-->
<logger name="org.springframework" level="INFO"></logger>
<logger name="org.mybatis" level="INFO"></logger>
<root level="INFO">
<appender-ref ref="RollingFileDebug"/>
<appender-ref ref="RollingFileInfo"/>
<appender-ref ref="RollingFileWarn"/>
<appender-ref ref="RollingFileError"/>
</root>
</loggers>直接コンソールログに削除されました。一部の人々が求めることができる：ログ出力を読んでいませんか？問題はどのように行うには？実際には、ログはまだ表示することができます。我々はすでにDEBUG.LOG、info.log、error.logファイルおよびその他の設定ファイルを持っていることを確認し、異なる出力レベルに基づいて、これらのファイルもリアルタイムで更新されます。そして、実際には、この場合のコンソールログ一切不要、そしてこのようなものは使用のために開発に適しています。
この問題を解決した後、我々はあなたがログがアーカイブされているか、以下の構成を、知っているかどうかを知りませんが、コンフィギュレーション・アーカイブ・ログを見続けています。ファイルをアーカイブするかを達した後のログのさまざまなレベル？1つのレベルアーカイブのアーカイブ1日少数のファイルアップ？ファイルの数が一杯になった、出力ログバックはどのように行うには？
<RollingFile name="RollingFileDebug" fileName="${fileName}/debug.log"
filePattern="${fileName}/$${date:yyyy-MM}/debug-%d{yyyy-MM-dd}-%i.log">
<!--控制台只输出level及以上级别的信息（onMatch），其他的直接拒绝（onMismatch）-->
<ThresholdFilter level="debug" onMatch="ACCEPT" onMismatch="DENY"/>
<PatternLayout pattern="[xxx] [%d{yyyy-MM-dd HH:mm:ss,SSS}] [%t] [%p] %c{1}:%L - %m%n"/>
<Policies>
<TimeBasedTriggeringPolicy/>
<SizeBasedTriggeringPolicy size="10 MB"/>
</Policies>
<DefaultRolloverStrategy />
</RollingFile>実際には、非常に単純な、上記の構成の内容は、これらの3行を注意してください。
<TimeBasedTriggeringPolicy/>
<SizeBasedTriggeringPolicy size="10 MB"/>
<DefaultRolloverStrategy/>最初の行手段：かかわらず（のような：DEBUG.LOG）現在のマスターファイルのタイムトリガアーカイブ、すなわち特定の時間に、によって、どのくらいのアーカイブ（このような出力として、次のとおりです。デバッグ-2019-10-01- 1.log）;
マスターファイルは10Mアーカイブファイルに達する：という2列目の手段。
三行目手段：保存されたアルゴリズムに従ってスクロール、同じ日に1次ログ・ファイルのレベルを保存されているアーカイブの数。上記の使用は、メイン7毎日にデフォルトのアルゴリズムは、デフォルトのアーカイブファイルをバックアップしています。
上記構成により、ディレクトリ内のログファイルの一覧は以下の./2019-10/：
その後、1日レベルのデフォルトのドキュメントは、7十分に保存されていますか？記事のように7つだけがまだ十分でないままに、上記ログ出力を大量に言及しましたか？右、実際には、我々は上記の三行の構成を設定することができ、そのようなファイルアーカイブの限界最大設定としてパラメータ分、属性の最大数を追加= 20、より多くのコピーがログファイルを保存することができます。
もちろん、より多くのログファイルを、より多くのディスクスペースが占有するだけでなく、それの十分でない場合は20を設定しますか？残りの新しいログを失うことはないのですか？
実際には、デフォルトDefaultRolloverStrategyのアーカイブ戦略がある：1日、そしてフロントによる-1改名ログファイル番号の終わり、そして最終的には、新たに生成されたの数が最も多い新しいログファイルを作成することを最も古いログを削除します。言い換えれば、新しいログ、はい、裸の男性スラグ特性の保存、古いログを捨てる - >草は、常に環境に優しいです。しかし、この状況はより多くの我々の見解に沿ったものでもログです：問題を経験した後、一般的なオンライン、我々はすべてのように、最近の情報のエラーログがある場合、参照エラーを発見し、問題を解決します。
私たちのプロジェクトのログがより重要である場合はもちろん、そのような支払い関連のシステムとして、失うことはありませんでした。したがって、上記のアプローチは、ログファイルにはあまり適していない、常に保存されなければならない、ラインELKログ管理システムのログを構築することにより、治療のために考慮することができます。しかし、このためには、この記事の焦点ではない、ないに言及し、将来は話す機会を持っています。
私たちが何かを使用することを願っています将来的には、より多くの参照熟考することができ、構成が少なくとも何をすべきか知っている、異なる環境に適しているので、コードのことは自分をノックアウト自信になります。さて、今日はこれまで、次の問題は、実際にデザインパターンを開始したい、ハハ！
第もっと世間の注目を取得し、オーノー質問をすることができる公共の場での問題があります。
強い兄100100強制
百千百のプログラミング、インターネットと何も新たな洞察を強制しました
