背景
在項目中常常被log4j的各類依賴衝突搞的焦頭爛額,久病成良醫啊,在這裏記錄一下我對log4j的理解與分析java
log4j 與 log4j2
log4j2是log4j的升級版,兩者互不兼容,聽說log4j2帶來了十倍的性能提高,因此基本上再也不使用log4j1web
那麼log4j 1代的依賴長什麼樣呢?apache
<artifactId>log4j</artifactId> <groupId>log4j</groupId>
log4j2的依賴編程
<dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.11.0</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.11.0</version> </dependency>
若是你的項目是web項目,最好加上api
<dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-web</artifactId> <version>2.11.0</version> </dependency>
slf4j
slf4j全稱爲Simple Logging Facade for JAVA,java簡單日誌門面。相似於Apache Common-Logging,是對不一樣日誌框架提供的一個門面封裝,能夠在部署的時候不修改任何配置便可接入一種日誌實現方案。可是,他在編譯時靜態綁定真正的Log庫。使用SLF4J時,若是你須要使用某一種日誌實現,那麼你必須選擇正確的SLF4J的jar包的集合(各類橋接包)。app
slf4j靜態綁定原理:SLF4J 會在編譯時會綁定import org.slf4j.impl.StaticLoggerBinder; 該類裏面實現對具體日誌方案的綁定接入。任何一種基於slf4j 的實現都要有一個這個類。如:org.slf4j.slf4j-log4j12-1.5.6: 提供對 log4j 的一種適配實現。注意:若是有任意兩個實現slf4j 的包同時出現,那麼就可能出現問題。框架
slf4j 的依賴咱們後面再分析,不一樣的實現對應不一樣的依賴dom
<dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.25</version> </dependency>
common-logging
common-logging是apache提供的一個通用的日誌接口。用戶能夠自由選擇第三方的日誌組件做爲具體實現,像log4j,或者jdk自帶的logging, common-logging會經過動態查找的機制,在程序運行時自動找出真正使用的日誌庫。固然,common-logging內部有一個Simple logger的簡單實現,可是功能很弱。因此使用common-logging,一般都是配合着log4j來使用。使用它的好處就是,代碼依賴是common-logging而非log4j, 避免了和具體的日誌方案直接耦合,在有必要時,能夠更改日誌實現的第三方庫。maven
common-logging的依賴ide
<artifactId>commons-logging</artifactId> <groupId>commons-logging</groupId>
slf4j 與 common-logging 比較
common-logging經過動態查找的機制,在程序運行時自動找出真正使用的日誌庫。因爲它使用了ClassLoader尋找和載入底層的日誌庫, 致使了象OSGI這樣的框架沒法正常工做,由於OSGI的不一樣的插件使用本身的ClassLoader。 OSGI的這種機制保證了插件互相獨立,然而卻使Apache Common-Logging沒法工做。
slf4j在編譯時靜態綁定真正的Log庫,所以能夠再OSGI中使用。另外,SLF4J 支持參數化的log字符串,避免了以前爲了減小字符串拼接的性能損耗而不得不寫的if(logger.isDebugEnable()),如今你能夠直接寫:logger.debug(「current user is: {}」, user)。拼裝消息被推遲到了它可以肯定是否是要顯示這條消息的時候,可是獲取參數的代價並無倖免(能夠經過lambda達到延遲生成參數的效果)。
public static void delayDebug(Supplier<String> message) { if (log.isDebugEnabled()) { log.debug(message.get()); } }
LogBack
Logback是由log4j創始人設計的又一個開源日記組件。logback當前分紅三個模塊:logback-core,logback- classic和logback-access。logback-core是其它兩個模塊的基礎模塊。logback-classic是log4j的一個 改良版本。此外logback-classic完整實現SLF4J API使你能夠很方便地更換成其它日記系統如log4j或JDK14 Logging。logback-access訪問模塊與Servlet容器集成提供經過Http來訪問日記的功能。
logback的依賴
<dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> </dependency>
(聽上去logback比log4j2更好,往後能夠考慮切換到logback)
Log4j 與 LogBack 比較
LogBack做爲一個通用可靠、快速靈活的日誌框架,將做爲Log4j的替代和SLF4J組成新的日誌系統的完整實現。LOGBack聲稱具備極佳的性能,「 某些關鍵操做,好比斷定是否記錄一條日誌語句的操做,其性能獲得了顯著的提升。這個操做在LogBack中須要3納秒,而在Log4J中則須要30納秒。 LogBack建立記錄器(logger)的速度也更快:13微秒,而在Log4J中須要23微秒。更重要的是,它獲取已存在的記錄器只需94納秒,而 Log4J須要2234納秒,時間減小到了1/23。跟JUL相比的性能提升也是顯著的」。 另外,LOGBack的全部文檔是全面免費提供的,不象Log4J那樣只提供部分免費文檔而須要用戶去購買付費文檔。
實戰
咱們在項目中使用的log4j2,引入了log4j2的依賴,而且強制幹掉了其它日誌組件的依賴,同時使用slf4j橋接其它日誌組件到log4j2的實現
log4j2的依賴
<dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.11.0</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.11.0</version> </dependency>
若是你的項目是web項目,最好加上
<dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-web</artifactId> <version>2.11.0</version> </dependency>
強制幹掉了其它日誌組件的依賴
藉助於idea的maven-helper組件,以及maven的maven-enforcer-plugin插件進行驗證
配置
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-enforcer-plugin</artifactId> <version>1.4.1</version> <executions> <execution> <id>enforce</id> <goals> <goal>enforce</goal> </goals> <configuration> <rules> <bannedDependencies> <!--是否檢查傳遞性依賴(間接依賴)--> <searchTransitive>true</searchTransitive> <excludes> <!--groupId[:artifactId][:version][:type][:scope][:classifier]--> <exclude>com.google.collections:google-collections</exclude> <exclude>log4j</exclude> <exclude>slf4j-log4j12</exclude> <exclude>commons-logging</exclude> <exclude>ch.qos.logback</exclude> <exclude>org.slf4j:slf4j-jdk14</exclude> <exclude>org.slf4j:slf4j-simple</exclude> <exclude>org.slf4j:slf4j-nop</exclude> <exclude>org.slf4j:slf4j-jcl</exclude> <!--把log4j的日誌都轉發到slf4j,咱們最終使用的是log4j實現,去掉這行的話slf4j就構成循環了--> <exclude>org.apache.logging.log4j:log4j-to-slf4j</exclude> </excludes> <message>Must not use google-collections, use guava</message> </bannedDependencies> </rules> </configuration> </execution> </executions> </plugin>
slf4j橋接其它日誌組件
<!--commons logging到slf4j的實現--> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.7.25</version> </dependency> <!--log4j1到slf4j的實現--> <dependency> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> <version>1.7.25</version> </dependency> <!--java util logging--> <dependency> <groupId>org.slf4j</groupId> <artifactId>jul-to-slf4j</artifactId> <version>1.7.25</version> </dependency>
slf4j到log4j2的實現
<dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> <version>2.11.0</version> </dependency>
slf4j與其它各類日誌組件的橋接圖
應用代碼中使用slf4j接口,接入具體實現的方法
應用代碼中使用別的日誌接口,轉成slf4j的方法
日誌組件相關歷史
Java 界裏有許多實現日誌功能的工具,最先獲得普遍使用的是 log4j,許多應用程序的日誌部分都交給了 log4j,不過做爲組件開發者,他們但願本身的組件沒關係緊依賴某一個工具,畢竟在同一個時候還有不少其餘不少日誌工具,假如一個應用程序用到了兩個組件,剛好兩個組件使用不一樣的日誌工具,那麼應用程序就會有兩份日誌輸出了。
爲了解決這個問題,Apache Commons Logging (以前叫 Jakarta Commons Logging,JCL)粉墨登場,JCL 只提供 log 接口,具體的實現則在運行時動態尋找。這樣一來組件開發者只須要針對 JCL 接口開發,而調用組件的應用程序則能夠在運行時搭配本身喜愛的日誌實踐工具。
因此即便到如今你仍會看到不少程序應用 JCL + log4j 這種搭配,不過當程序規模愈來愈龐大時,JCL的動態綁定並非總能成功,具體緣由你們能夠 Google 一下,這裏就再也不贅述了。解決方法之一就是在程序部署時靜態綁定指定的日誌工具,這就是 SLF4J 產生的緣由。
跟 JCL 同樣,SLF4J 也是隻提供 log 接口,具體的實現是在打包應用程序時所放入的綁定器(名字爲 slf4j-XXX-version.jar)來決定,XXX 能夠是 log4j12, jdk14, jcl, nop 等,他們實現了跟具體日誌工具(好比 log4j)的綁定及代理工做。舉個例子:若是一個程序但願用 log4j 日誌工具,那麼程序只需針對 slf4j-api 接口編程,而後在打包時再放入 slf4j-log4j12-version.jar 和 log4j.jar 就能夠了。
如今還有一個問題,假如你正在開發應用程序所調用的組件當中已經使用了 JCL 的,還有一些組建可能直接調用了 java.util.logging,這時你須要一個橋接器(名字爲 XXX-over-slf4j.jar)把他們的日誌輸出重定向到 SLF4J,所謂的橋接器就是一個假的日誌實現工具,好比當你把 jcl-over-slf4j.jar 放到 CLASS_PATH 時,即便某個組件本來是經過 JCL 輸出日誌的,如今卻會被 jcl-over-slf4j 「騙到」SLF4J 裏,而後 SLF4J 又會根據綁定器把日誌交給具體的日誌實現工具。過程以下
Component | | log to Apache Commons Logging V jcl-over-slf4j.jar --- (redirect) ---> SLF4j ---> slf4j-log4j12-version.jar ---> log4j.jar ---> 輸出日誌
看到上面的流程圖可能會發現一個有趣的問題,假如在 CLASS_PATH 裏同時放置 log4j-over-slf4j.jar 和 slf4j-log4j12-version.jar 會發生什麼狀況呢?沒錯,日誌會被踢來踢去,最終進入死循環。
因此使用 SLF4J 的比較典型搭配就是把 slf4j-api、JCL 橋接器、java.util.logging(JUL)橋接器、log4j 綁定器、log4j 這5個 jar 放置在 CLASS_PATH 裏。
不過並非全部APP容器都是使用 log4j 的,好比 Google AppEngine 它使用的是 java.util.logging(JUL),這時應用 SLF4J 的搭配就變成 slf4j-api、JCL橋接器、logj4橋接器、JUL綁定器這4個 jar 放置在 WEB-INF/lib 裏。
一組比較ok的log依賴,使用log4j2
<dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-api</artifactId> <version>2.11.0</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-web</artifactId> <version>2.11.0</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.11.0</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.25</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-slf4j-impl</artifactId> <version>2.11.0</version> </dependency> <!--commons logging到slf4j的實現--> <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.7.25</version> </dependency> <!--log4j1到slf4j的實現--> <dependency> <groupId>org.slf4j</groupId> <artifactId>log4j-over-slf4j</artifactId> <version>1.7.25</version> </dependency> <!--java util logging--> <dependency> <groupId>org.slf4j</groupId> <artifactId>jul-to-slf4j</artifactId> <version>1.7.25</version> </dependency>
一組比較ok的log4j2的配置
<?xml version="1.0" encoding="UTF-8"?> <Configuration status="info"> <Properties> <Property name="PRO_NAME">review-api</Property> <Property name="LOG_HOME">/home/work/log/${PRO_NAME}</Property> <Property name="PID">????</Property> <Property name="LOG_PATTERN"> %clr{%d{yyyy-MM-dd HH:mm:ss.SSS}}{faint} %clr{%5p} %clr{${sys:PID}}{magenta} %clr{---}{faint} %clr{[%t]}{faint} %clr{%c{1.}}{cyan} %clr{:}{faint} %m%n%xwEx </Property> </Properties> <Appenders> <Console name="Console" target="SYSTEM_OUT"> <PatternLayout> <!--<Pattern>${LOG_PATTERN}</Pattern>--> <Pattern>%d %p %c{1.} [%t] - %m%n</Pattern> </PatternLayout> </Console> <RollingRandomAccessFile name="rootFile" fileName="${LOG_HOME}/${PRO_NAME}-rootFile.log" filePattern="${LOG_HOME}/${PRO_NAME}-rootFile-%d{yyyy-MM-dd}.log.gz" append="true"> <PatternLayout> <Pattern>%d %p %c{1.} [%t] - %m%n</Pattern> </PatternLayout> <Policies> <!--在啓動時--> <OnStartupTriggeringPolicy/> <!--或在最小時間單位變更時--> <TimeBasedTriggeringPolicy interval="1" modulate="true"/> </Policies> <!--啓動如下策略--> <DefaultRolloverStrategy max="10"> <!--maxDepth:文件夾深度限制爲2--> <Delete basePath="${LOG_HOME}" maxDepth="2"> <IfFileName glob="**.log.gz"/> <!--日誌保存7天--> <IfLastModified age="7d"/> </Delete> </DefaultRolloverStrategy> </RollingRandomAccessFile> <RollingRandomAccessFile name="file" fileName="${LOG_HOME}/${PRO_NAME}.log" filePattern="${LOG_HOME}/${PRO_NAME}-%d{yyyy-MM-dd}.log.gz" immediateFlush="true" append="true"> <PatternLayout> <Pattern>%d %p %c{1.} [%t] - %m%n</Pattern> </PatternLayout> <Policies> <TimeBasedTriggeringPolicy interval="1" modulate="true"/> </Policies> </RollingRandomAccessFile> <RollingRandomAccessFile name="error" fileName="${LOG_HOME}/${PRO_NAME}-error.log" filePattern="${LOG_HOME}/${PRO_NAME}-error-%d{yyyy-MM-dd}.log.gz" immediateFlush="true" append="true"> <PatternLayout> <Pattern>%d %p %c{1.} [%t] - %m%n</Pattern> </PatternLayout> <Policies> <TimeBasedTriggeringPolicy interval="1" modulate="true"/> </Policies> </RollingRandomAccessFile> <ReviewLogAppender name="SELF_ELK" project-name="${PRO_NAME}"/> </Appenders> <Loggers> <logger name="com.company" level="error" additivity="false"> <AppenderRef ref="error" level="error"/> </logger> <logger name="com.company.middle" level="${log4j_level}" additivity="false"> <AppenderRef ref="file"/> <AppenderRef ref="SELF_ELK"/> <AppenderRef ref="Console"/> </logger> <logger name="com.company.browser" level="${log4j_level}" additivity="false"> <AppenderRef ref="file"/> <AppenderRef ref="SELF_ELK"/> <AppenderRef ref="Console"/> </logger> <Root level="info"> <AppenderRef ref="rootFile"/> </Root> </Loggers> </Configuration>
其中關於SELF_ELK的實現,咱們將全部日誌打到kibana上一份,方便咱們查看
/** * * 收集全部log日誌,打到elk上 */ @Plugin(name = "ReviewLogAppender", category = "Core", elementType = "appender", printObject = true) public class ReviewLogAppender extends AbstractAppender { private String project; public ReviewLogAppender(String name, Filter filter, Layout<? extends Serializable> layout, String project) { super(name, filter, layout); this.project = project; } @PluginFactory public static ReviewLogAppender create(@PluginAttribute("name") String name, @PluginElement("Layout") Layout<? extends Serializable> layout, @PluginElement("Filter") final Filter filter, @PluginAttribute("project-name") String project) { if (name == null) { return null; } if (layout == null) { layout = PatternLayout.createDefaultLayout(); } return new ReviewLogAppender(name, filter, layout, project); } @Override public void append(LogEvent logEvent) { if (!EnvVar.isProduction()) { return; } MiddleReviewDebugLog middleReviewDebugLog = new MiddleReviewDebugLog(); String logBody = logEvent.getMessage().getFormattedMessage(); middleReviewDebugLog.setFrom(project); middleReviewDebugLog.setLevel(logEvent.getLevel().toString()); middleReviewDebugLog.setTimestamp(System.currentTimeMillis()); middleReviewDebugLog.setLogbody(logBody); middleReviewDebugLog.setServerIp(IPUtils.getHostIp()); if (logEvent.getLevel().equals(Level.ERROR)) { StringBuilder stringBuilder = new StringBuilder(); final Throwable thrown = logEvent.getThrown(); if (thrown != null) { stringBuilder.append("errorMsg:").append(thrown.getMessage()).append("\nstackTrace:").append(ExceptionUtil.stacktraceToString(thrown)); } middleReviewDebugLog.setExt(stringBuilder.toString()); } LCS_LOGGER.write(TOPIC_AND_TEAM, middleReviewDebugLog); } }