Javaにおけるlog 4 jログレベル構成の詳細
6009 ワード
1.1はじめに
耻ずかしいですね.最近、お客様の会社にアウトソーシング开発の面接に派遣されました.もともと何のredis、rabbitMQ、SSMフレームワークに関する面接问题と自分がやったいくつかのプロジェクトの振り返りを用意して、自信を持って面接に行きました.结果、最近のプロジェクトで使われているログシステムは何ですか.ログ・レベルはどのように構成されていますか?その时、私はすべてXを蒙って、ふだんすべてプロジェクトのマネージャーが挂かって、私自身も胜手にインターネットを利用して配置のファイルを探して贴るとOKになりました.私がそう言った後、面接官は私を深く決めて、その時私の心は恥ずかしくて......
1.2雑談は少なく、日記の発展物語を話す(すでに知っているならスキップして、1.3日記の構成を直接見ることができる)
ログ技術を深く理解するには、個人的にはlogback+slf 4 jを見ることをお勧めします.ログ構成については、log 4 jを理解したほうがいいです.現在、ほとんどのプロジェクトはlog 4 jを使用しているからです.では、ログの発展についてお話しします.
1999年、Apacheオープンソースコミュニティはlog 4 jを発表し、一時的にプログラム界を騒がせ、それからログの標準となりjavaプログラマーに広く使用された.その後、Sun社もJDK 1.4版でLoggingメカニズム(java.util.logging、以下JULと略す)を発表したが、このメカニズムは公衆の承認を得ていないので、かわいそうだ.やがてApacheはcommons-loggingログフレームワーク(開発者がどのログ技術を具体的に使用するかに注目する必要がなく、抽象的なログ実現方式を実現することができ、一般的には携帯電話で滴滴を呼ぶ必要があります.もしあなたが北京にいたら、北京の滴滴を呼んで、香港では香港の滴滴を呼ぶことができます)を発売しました.このフレームワークはSun社への軽蔑のようです.ログ出力のために、現在の環境で呼び出されたログ技術を自動的に検索できます.ログフレームワークは、log 4 jまたはJULをサポートします.commons-logging+log 4 jはその後長い間Javaログの古典的な組み合わせとなった.しかしその後commons-loggingはしばらく更新されていませんが、commons-loggingの当初の設計が不十分だったのか、再最適化するのも難しいのではないでしょうか.なぜそう言ったのでしょうか.次の優れたログフレームワークslf 4 jが誕生したため、この著者(Ceki Gülcü)はlog 4 jの著者の一人であり、彼のslf 4 jは設計的に優雅であり、logback技術を実現し、log 4 jよりも最前線でもある.これで、ログシステムはcommons-logging+log 4 j一家の独大な局面から動揺し始め、各種commons-logging+log 4 j?slf4j+log4j?slf4j+logback?コーディネートは、本当に胸が締め付けられます.さらに恐ろしいことに、Ceki Gülcüの大物はまたlog 4 jの最適化を手伝って、それから世界にはもう一つのログ技術--log 4 j 2が増えました.これはテンセントを学んで微信とQQをしますか?本当に666です.したがって、ログ技術を深く理解したい場合は、logback+slf 4 jに関する資料を探すことができます.プロファイルについては、私が下に書いたlog 4 jの構成の詳細を知っておけばいいと思います.結局、今は多くの会社がlog 4 jフレームワークを使っています.
1.3本題に入り、log 4 jログの基本構成
1.プロジェクトのclasspathまたはresourceパッケージの下(mavenプロジェクト)にlog 4 j.propertiesファイルを新規作成します.初期プロジェクト構成は次のパラメータで十分です.より詳細な構成は続行できます.
1.4 log 4 jログレベルの構成を参照してください.
2.ログテストの構成結果を呼び出します.
1.4ログ・レベルの構成
ログ・レベル構成は、上記の構成が親ログ・レコーダを構成するログ・レベルであり、第2のクラスが子ログ・レコーダを構成するログ・レベルであり、第3のクラスが出力元(コンソール、ファイルなど)を構成するログ・レベルである3つのクラスに分けられます.ログ・レベルの解析の優先度は、下位から上位に並べられます.具体的な表現は私がはっきり言えないことを許して、直接ケースに行って、みんなは理解できるはずです!
1.親ログレコーダ(rootLogger)のログレベル(INFOレベルと仮定)が構成されていて、サブクラスログレコーダのログレベルが構成されていない場合、出力ソースのログレベルも構成されていない場合、出力ソースはINFOレベル以上のものしか出力できません.
2.親ログレコーダ(rootLogger)のログレベル(INFOレベルと仮定)が構成され、子ログレコーダのログレベル(DEBUGレベルと仮定)が構成され、出力元のログレベルが構成されていない場合、出力元出力DEBUGレベル以上である.
3.親ログレコーダ(rootLogger)のログレベル(INFOレベルと仮定)を構成し、子ログレコーダのログレベル(DEBUGレベルと仮定)を構成し、出力元のログレベル(INFOレベルと仮定)を構成した場合、出力元はINFOレベル以上を出力する.
4.親ログレコーダ(rootLogger)のログレベル(INFOレベルと仮定)が設定されている場合、サブクラスログレコーダのログレベルが設定されていない場合、構成
出力元のログレベル(DEBUGレベルと仮定)がある場合、出力元はINFOレベル以上を出力する.
したがって、上記の例から、ログレコーダと出力ソースの出力ログレベルには2つの論理関係があることがわかります.
1.出力元ログ・レベルが定義されていない場合、サブクラスのログ・レコーダに最も近いログ・レベルが継承されます.サブクラス・ログ・レコーダは、ログ・レベルを定義していません.このログ・レコーダは、その親に最も近いログ・レコーダを継承します.
2.ログを印刷する際、出力元は、自身が定義したログ・レベルに基づいて、最も近いサブクラスのログ・レコーダが定義したログ・レベルと比較し、出力元がサブクラスのログ・レコーダよりも高いレベルであれば、出力元が定義したログ・レベルでログを出力し、逆にサブクラスのログ・レコーダのログ・レベルで出力します.
したがって、プロジェクトでは、日次構成でログ・レベルを構成できます.
1.5終わりの言葉
これで、あなたのログの構成が基本的に把握されていると信じています.文の中には間違っているところがたくさんあるかもしれませんが、大侠の指摘を歓迎します.私もこの技術の配置を深く理解するために、文章を書いてまとめました.そうすれば、私はそれをもっと深く理解することができます.
耻ずかしいですね.最近、お客様の会社にアウトソーシング开発の面接に派遣されました.もともと何のredis、rabbitMQ、SSMフレームワークに関する面接问题と自分がやったいくつかのプロジェクトの振り返りを用意して、自信を持って面接に行きました.结果、最近のプロジェクトで使われているログシステムは何ですか.ログ・レベルはどのように構成されていますか?その时、私はすべてXを蒙って、ふだんすべてプロジェクトのマネージャーが挂かって、私自身も胜手にインターネットを利用して配置のファイルを探して贴るとOKになりました.私がそう言った後、面接官は私を深く決めて、その時私の心は恥ずかしくて......
1.2雑談は少なく、日記の発展物語を話す(すでに知っているならスキップして、1.3日記の構成を直接見ることができる)
ログ技術を深く理解するには、個人的にはlogback+slf 4 jを見ることをお勧めします.ログ構成については、log 4 jを理解したほうがいいです.現在、ほとんどのプロジェクトはlog 4 jを使用しているからです.では、ログの発展についてお話しします.
1999年、Apacheオープンソースコミュニティはlog 4 jを発表し、一時的にプログラム界を騒がせ、それからログの標準となりjavaプログラマーに広く使用された.その後、Sun社もJDK 1.4版でLoggingメカニズム(java.util.logging、以下JULと略す)を発表したが、このメカニズムは公衆の承認を得ていないので、かわいそうだ.やがてApacheはcommons-loggingログフレームワーク(開発者がどのログ技術を具体的に使用するかに注目する必要がなく、抽象的なログ実現方式を実現することができ、一般的には携帯電話で滴滴を呼ぶ必要があります.もしあなたが北京にいたら、北京の滴滴を呼んで、香港では香港の滴滴を呼ぶことができます)を発売しました.このフレームワークはSun社への軽蔑のようです.ログ出力のために、現在の環境で呼び出されたログ技術を自動的に検索できます.ログフレームワークは、log 4 jまたはJULをサポートします.commons-logging+log 4 jはその後長い間Javaログの古典的な組み合わせとなった.しかしその後commons-loggingはしばらく更新されていませんが、commons-loggingの当初の設計が不十分だったのか、再最適化するのも難しいのではないでしょうか.なぜそう言ったのでしょうか.次の優れたログフレームワークslf 4 jが誕生したため、この著者(Ceki Gülcü)はlog 4 jの著者の一人であり、彼のslf 4 jは設計的に優雅であり、logback技術を実現し、log 4 jよりも最前線でもある.これで、ログシステムはcommons-logging+log 4 j一家の独大な局面から動揺し始め、各種commons-logging+log 4 j?slf4j+log4j?slf4j+logback?コーディネートは、本当に胸が締め付けられます.さらに恐ろしいことに、Ceki Gülcüの大物はまたlog 4 jの最適化を手伝って、それから世界にはもう一つのログ技術--log 4 j 2が増えました.これはテンセントを学んで微信とQQをしますか?本当に666です.したがって、ログ技術を深く理解したい場合は、logback+slf 4 jに関する資料を探すことができます.プロファイルについては、私が下に書いたlog 4 jの構成の詳細を知っておけばいいと思います.結局、今は多くの会社がlog 4 jフレームワークを使っています.
1.3本題に入り、log 4 jログの基本構成
1.プロジェクトのclasspathまたはresourceパッケージの下(mavenプロジェクト)にlog 4 j.propertiesファイルを新規作成します.初期プロジェクト構成は次のパラメータで十分です.より詳細な構成は続行できます.
1.4 log 4 jログレベルの構成を参照してください.
#
# ： debug < info < warn < error < fatal
# (info) (console,myFile)
# ， info
log4j.rootLogger=info,console,myFile
####### console #######
# console（ ）
# ConsoleAppender（ ）log4j.appender.console=org.apache.log4j.ConsoleAppender
# PatternLayout
log4j.appender.console.layout=org.apache.log4j.PatternLayout
#
log4j.appender.console.layout.ConversionPattern=%d %-5p [%c.%M()] - %m%n
####### myFile #######
# myFile（ ）
# RollingFileAppender（ ）log4j.appender.myFile=org.apache.log4j.RollingFileAppender
#
log4j.appender.myFile.File=src/log/logProperties/log4j.log
#
log4j.appender.myFile.MaxFileSize=1024kb
# （ 0 1 ， 3 ）
#
log4j.appender.myFile.MaxBackupIndex=2
# PatternLayout
log4j.appender.myFile.layout=org.apache.log4j.PatternLayout
#
log4j.appender.console.layout.ConversionPattern=%d %-5p [%c.%M()] - %m%n
####### #######
#%d: ， ISO8601， ，
# ： %d{yyy MM dd HH mm ss SSS}， ：
#2018 01 06 14 47 45 590
#%p: ， DEBUG，INFO，WARN，ERROR，FATAL
#%-5p： 5 ， （ “-” ），
#%c:
#%M:
#%m:
#%n:
#%L: 2.ログテストの構成結果を呼び出します.
import org.apache.log4j.LogManager;
import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;
public class LogPropertiesTest {
public static void main(String[] args) {
/* classpath
String log4jPath=System.getProperty("user.dir")+"\\src\\log\\logProperties\\log4j.properties";
PropertyConfigurator.configure(log4jPath);*/
Logger log = LogManager.getLogger(LogPropertiesTest.class);
log.debug(" ");
log.info(" ");
log.warn(" ");
log.error(" ");
log.fatal(" ");
}
}1.4ログ・レベルの構成
ログ・レベル構成は、上記の構成が親ログ・レコーダを構成するログ・レベルであり、第2のクラスが子ログ・レコーダを構成するログ・レベルであり、第3のクラスが出力元(コンソール、ファイルなど)を構成するログ・レベルである3つのクラスに分けられます.ログ・レベルの解析の優先度は、下位から上位に並べられます.具体的な表現は私がはっきり言えないことを許して、直接ケースに行って、みんなは理解できるはずです!
1.親ログレコーダ(rootLogger)のログレベル(INFOレベルと仮定)が構成されていて、サブクラスログレコーダのログレベルが構成されていない場合、出力ソースのログレベルも構成されていない場合、出力ソースはINFOレベル以上のものしか出力できません.
2.親ログレコーダ(rootLogger)のログレベル(INFOレベルと仮定)が構成され、子ログレコーダのログレベル(DEBUGレベルと仮定)が構成され、出力元のログレベルが構成されていない場合、出力元出力DEBUGレベル以上である.
3.親ログレコーダ(rootLogger)のログレベル(INFOレベルと仮定)を構成し、子ログレコーダのログレベル(DEBUGレベルと仮定)を構成し、出力元のログレベル(INFOレベルと仮定)を構成した場合、出力元はINFOレベル以上を出力する.
4.親ログレコーダ(rootLogger)のログレベル(INFOレベルと仮定)が設定されている場合、サブクラスログレコーダのログレベルが設定されていない場合、構成
出力元のログレベル(DEBUGレベルと仮定)がある場合、出力元はINFOレベル以上を出力する.
したがって、上記の例から、ログレコーダと出力ソースの出力ログレベルには2つの論理関係があることがわかります.
1.出力元ログ・レベルが定義されていない場合、サブクラスのログ・レコーダに最も近いログ・レベルが継承されます.サブクラス・ログ・レコーダは、ログ・レベルを定義していません.このログ・レコーダは、その親に最も近いログ・レコーダを継承します.
2.ログを印刷する際、出力元は、自身が定義したログ・レベルに基づいて、最も近いサブクラスのログ・レコーダが定義したログ・レベルと比較し、出力元がサブクラスのログ・レコーダよりも高いレベルであれば、出力元が定義したログ・レベルでログを出力し、逆にサブクラスのログ・レコーダのログ・レベルで出力します.
したがって、プロジェクトでは、日次構成でログ・レベルを構成できます.
# info， info
log4j.rootLogger=info,console
# error,
log4j.logger.log.logProperties=error
# debug,
log4j.logger.log.logProperties.LogPropertiesTest=debug
############# #############
# api
log4j.appender.console=org.apache.log4j.ConsoleAppender
# ， ，
#log4j.appender.console.Threshold = info
# ：
log4j.appender.console.layout=org.apache.log4j.PatternLayout
#
log4j.appender.console.layout.ConversionPattern=%d %-2p [%c.%M()] - %m%n 1.5終わりの言葉
これで、あなたのログの構成が基本的に把握されていると信じています.文の中には間違っているところがたくさんあるかもしれませんが、大侠の指摘を歓迎します.私もこの技術の配置を深く理解するために、文章を書いてまとめました.そうすれば、私はそれをもっと深く理解することができます.