이 기사는 주로 Java Engineering에서 SLF4J+로그백의 구성을 소개합니다.
SLF4J+로그백 구성을 도입하기 전에 먼저 로그 구성 요소의 로그백 로그백을 소개합니다.
(1) 로그 구성 요소 로그백의 소개 및 구성
1. 로그백 소개
Logback은 Log4J의 설립자가 설계 한 또 다른 오픈 소스 로그 구성 요소입니다. 로그백은 현재 로그백 코어, 로그 백 클래스 및 로그백 활성의 세 가지 모듈로 나뉩니다. 로그백 코어는 다른 두 모듈의 기본 모듈입니다. Logback-Classic은 Log4J의 개선 된 버전입니다. 또한 Logback Classic은 SLF4J API를 완전히 구현하여 LOG4J 또는 JDK14 로깅과 같은 다른 로깅 시스템으로 쉽게 교체 할 수 있습니다. 로그백 액세스 액세스 모듈은 서블릿 컨테이너와 통합되어 HTTP를 통해 로그에 액세스하는 기능을 제공합니다. 로그백은 다음과 같이 두 가지 구성 요소와 SLF4J를 결합한 공식 웹 사이트입니다.
Logback의 공식 웹 사이트 : http://logback.qos.ch
SLF4J의 공식 웹 사이트 : http://www.slf4j.org
이 기사에 사용 된 구성 요소는 다음과 같습니다. 공식 웹 사이트로 이동하여 다운로드하십시오!
로그백 액세스 -.0.0.jar
로그 백 클래스 -.0.0.jar
로그백 코어 -1.0.0.jar
SLF4J-API-1.6.0.jar
2. 로그백이 log4J를 대체하는 이유 :
Logback과 Log4J는 매우 유사합니다. Log4J에 익숙합니다. 다음은 Log4J를 통한 로그백의 몇 가지 장점입니다.
1. 더 빠르게 로그백의 커널 재 작성을 구현하고 일부 주요 실행 경로에서 성능이 10 배 이상 증가합니다. 또한 로그백은 성능을 향상시킬뿐만 아니라 초기화 된 메모리로드가 적습니다.
2. 매우 완전한 테스트 로그백은 몇 년 동안 수많은 시간 동안 테스트되었습니다. 로그백의 테스트는 완전히 다릅니다. 저자의 관점에서 볼 때 이것은 log4J 대신 로그백을 선택하는 간단하고 중요한 이유입니다.
3. Logback-Classic은 SLF4J를 달성하기 위해 SLF4J 로그 백 클래스로 자연스럽게 구현됩니다. SLF4J를 사용하면 로그 백 클래스를 느낄 수 없습니다. 또한 Logback-Classic은 SLF4J를 매우 자연스럽게 구현하기 때문에 Log4J 또는 기타로 전환하는 것은 다른 JAR 패키지로 제공하는 것이 좋습니다.
4. 매우 전체 문서 공식 웹 사이트에는 200 페이지가 넘는 문서가 있습니다.
5. 구성 파일을 구성 파일의 수정으로 자동로드하면 Logback Classic은 구성 파일을 자동으로 다시로드 할 수 있습니다. 스캐닝 프로세스는 빠르고 안전하며 다른 스캐닝 스레드를 만들 필요가 없습니다. 이 기술은 응용 프로그램이 JEE 환경에서 실행될 수 있음을 충분히 보장합니다.
6. Lilith Lilith는 LOG4J 전기 톱과 유사한 로그 사건의 관찰자입니다. Lilith는 많은 양의 로그 데이터를 처리 할 수 있습니다.
7.주의 모드와 매우 친근한 복구주의 모드에서 여러 개의 FileAppender 인스턴스가 여러 JVM에서 실행되며 동일한 로그 파일을 안전하게 쓸 수 있습니다. RollingFileAppender에는 몇 가지 제한 사항이 있습니다. Logback의 fileappender와 RollingFileAppender를 포함한 서브 클래스는 I/O 예외에서 매우 친절하게 복구 할 수 있습니다.
8. 구성 파일은 다른 상황을 처리 할 수 있습니다. 이러한 구성 파일은 단지 작은 차이로, 구현 및 구현할 수 있으므로 구성 파일이 여러 환경에 적응할 수 있습니다.
9. 필터 (필터) 때때로 문제가 필요하고 로그가 필요합니다. Log4J에서는 로그 레벨 만 줄이지 만 로그가 많은 로그를 만들고 응용 프로그램 성능에 영향을 미칩니다. Logback에서는 해당 로그 레벨을 계속 유지하고 예를 들어 사용자 로그인하면 디버그 레벨에서 로그가 재생되고 다른 사용자는 계속해서 경고 수준에서 플레이 할 수 있습니다. 이 기능을 달성하려면 4 줄의 XML 구성 만 추가하면됩니다. MDCFilter를 참조 할 수 있습니다.
10. SiftingAppener (매우 다기능 부가관) 주어진 작동 매개 변수에 따라 로그 파일을 나눌 수 있습니다. 예를 들어, SiftingAppender는 사용자 세션을 따르는 사용자 세션을 구별 할 수 있으며 각 사용자에게 로그 파일이 있습니다.
11. 새 파일을 생성 할 때 rollingFileAppender를 자동으로 압축하면 자동으로 재생 된 로그 파일이 압축됩니다. 압축은 비동기 프로세스이므로 큰 로그 파일의 경우에도 응용 프로그램이 압축 프로세스에 영향을 미치지 않습니다.
스택 트리에는 스택 트리 로그를 재생할 때 패키지 버전이 있습니다.
13. TimeBasedRollingPolicy 또는 SizeAndTimeBasedFNATP의 Maxhistory 속성을 설정하여 이전 로그 파일을 자동으로 제거하십시오. Maxhistory 12가 설정되면 12 개월이 넘는 로그 파일은 자동으로 제거됩니다.
요컨대, 로그백은 Log4J보다 낫습니다.
3. 로그백 구성 소개
1. 로거, appender 및 레이아웃
로그는 로그의 레코더로서 사용되는 해당 컨텍스트와 관련하여 로그 유형과 레벨을 정의 할 수 있습니다.
Appender는 주로 로그 출력의 대상을 지정하는 데 사용됩니다.
레이아웃은 이벤트의 문자열, 형식화 된 로그 정보로의 출력을 담당합니다.
2. 로거 컨텍스트
각 Logger는 LoggerContext와 관련이 있으며 Logger는 Logger를 제작할 책임이 있으며 각 Logger를 트리 구조로 정렬 할 책임이 있습니다. 다른 모든 로거는 또한 org.slf4j.loggerfactory class getLogger의 정적 방법을 통해 얻었습니다. GetLogger 메소드는 Logger에 의해 명명되었습니다. 동일한 이름을 사용하여 LoggerFactory.getLogger 메소드를 호출하는 것은 항상 동일한 Logger 객체에 대한 참조입니다.
3. 유효 수준과 수준의 상속
로거를 할당 할 수 있습니다. 레벨에는 다음이 포함됩니다 : 추적, 디버그, 정보, 경고 및 오류는 ch.qos.logback.classic.level 클래스에 정의됩니다. 로거가 할당되지 않으면 분포 수준의 가장 가까운 조상에서 레벨을 상속합니다. 루트 로거의 기본 레벨은 디버그입니다.
4. 인쇄 방법 및 기본 선택 규칙 <br /> 인쇄 방법 요청 수준을 결정합니다. 예를 들어, l이 로거 인스턴스 인 경우 l.info ( "..")는 레벨 정보가있는 레코드 문입니다. 로그 요청 수준은 로거의 유효한 수준보다 높거나 동일 할 때 활성화 된 것으로 호출되며, 그렇지 않으면 비활성화 된 것으로 호출됩니다. 레코드 요청 레벨은 P이며 로거의 유효한 레벨은 q입니다.
이 규칙은 로그백의 핵심입니다. 레벨 정렬은 다음과 같습니다. TRACE <DEBUG <info <WARN <ERROR
4. Logback의 기본 구성 <br /> 구성 파일 Logback-Test.xml 및 logback.xml이 존재하지 않으면 Logback은 기본적으로 Basic ConfigUrator를 호출하여 최소화 된 구성을 생성합니다. 루트 로거와 관련된 컨소시너로 구성된 구성을 최소화합니다. 출력 모드는 %d {hh : mm : ss.sss} [ %스레드] %-5level %logger {36} - %msg %n의 PatternLayoutenDCoder입니다. 루트 로거의 기본 레벨은 디버그입니다.
1. 로그백의 구성 파일
로그백 구성 파일의 구문은 매우 유연합니다. 유연성으로 인해 DTD 또는 XML 스키마를 정의 할 수 없습니다. 그럼에도 불구하고, 구성 파일의 기본 구조를 이러한 방식으로 설명 할 수 있습니다. <configuration>로 시작하면 <ppender> 요소가 0 이상, 0 이상 <gogger> 요소 및 최대 <루트> 요소가 있습니다.
2. 로그백의 기본 구성 단계
(1). ClassPath에서 파일 logback-test.xml을 찾아보십시오.
(2). 파일이 존재하지 않는 경우 파일 logback.xml을 찾으십시오.
(3)... 파일이 존재하지 않으면 Logback은 BAS ICConfigURATOR를 사용하여 자동으로 자체를 구성하여 레코드 출력이 콘솔에 발생합니다.
3. logback.xml 파일
<? appender name = "stdout"> <!-로그 출력 인코딩-> <인코딩> utf-8 </encoding> <laayout> <!-형식 출력 :%d를 의미합니다. 레벨 5 왼쪽 디스플레이에서 문자 너비 5 문자 너비%MSG : 로그 메시지,%n은 변경 기호-> <S.SSS} [%스레드]%- 5 줄 %로거 {50}- %msg %n </pattern> </layout> </appender> <!-매일 생성 로그 파일-> <ppender name = "file"> <comoding> UTF-8 </ 인코딩> <RollingPolicy> <!-로그 파일-<filenamepattern> $ {log_home} /myapp.log.%d {yyyy-mm-dd}에 의한 파일 이름 /maxhistory> </rollingpolice> <layout> <!-공식화 된 출력 :%d는 날짜를 나타내고,%스레드는 스레드 이름을 나타내고,%d는 스레드 이름을 나타냅니다. 로그 메시지,%n은 변화 특성-> <패턴>%d {yyyy-mm-dd hh : mm : ss.sss} [%스레드]%-5level%logger {50}-%msg%n </패턴 > </layout> <!-로그 파일의 가장 큰 크기-> <TriggeringPolice> <maxFilesize> 10MB </maxFilesize> </triggeringpolice> </appen der> <!-최대 절전 모드 SQL에 대한 매개 변수 표시 -> <logger name = "Organnate.type.descriptor.sql.basicbinder ="trace " /> <logger ="org.hibernate. org.hibernate.sql "level ="def " /> <log. erameters"level = "debug" /> <logger name = "org.hibernate.eengine.qury.hqlqueryplan"level = "debug" /<!- 로그 출력 레벨-> <루트 레벨 = "정보"> <ppender-ref = "stdout" /> <ppender-ref ref = "file" /> < /root> <!-데이터베이스에 로그인-> <ppender name = "db"> <! onnectionsource> <!-연결 풀-> <dataSource> <DriverClass> com.mysql.jdbc.driver </driverclass> <Url> JDBC : mysql : //127.0.1 : 3306/ DatabasEname </url> <user> root </user> <password> root </passwor> </dataSource> </connectionSource> </appender> -> </configuration >> </configuration >> </configuration >> </구성 >> 5. 참조 로그백 프로그램을 사용하십시오
package com.stu.system.action; import org.slf4j.logger; import org.slf4j.loggerfactory; public class blogaction {// loggerfactory를 통해 얻은 전역 로그거 정의 클래스); / ** @param args * / public static void main (string [] args) {logger.info ( "logback success");다음으로 Java 프로젝트에서 SLF4J+로그백 구성을 소개하겠습니다.
1. Maven- 기반 SLF4J+LOGBACK POM.XML 구성
<pectionency> <groupid> org.slf4j </groupid> <artifactid> slf4j-api </artifactid> <버전> 1.7.10 </version> </efcevency> <groupid> c h.qos.logback </groupid> <artifactid> logback-classic </artifactid> <bersion> 1.1.2 </deendecy> <g.qos /버전> </의존성>
2. ClassPath 디렉토리에서 새 logback.xml 구성 파일 생성
<? xml version = "1.0"encoding = "utf-8"?> <!-스캔 :이 속성이 true로 설정되면 구성 파일이 변경되면 다시로드되고 기본값이 true입니다. SCANPERIOD : 시간 간격을 설정하여 구성 파일이 제공되지 않으면 기본 장치는 밀리 초입니다. 기본 시간 간격은 1 분입니다. 디버그 :이 속성이 true로 설정되면 로그백 내부 로그 정보가 인쇄되어 로그백의 실행 상태를 실시간으로 확인합니다. 기본값은 False입니다. -> <configuration scan = "false"scanperiod = "60 초"Debug = "false"> <!-로그의 루트 디렉토리 정의-> <속성 이름 = "log_home"value = "/app/log " /> <!-로그 파일 이름 정의-> <속성 이름 ="AppName "value ="netty "> < / property> <!-ch.qos.logback.core.consoleApender 표시 콘솔 출력-> <appender name = "stdout"> <concoding> utf-8 </encoding> <!-로그 출력 형식 :%d 평균 날짜,%스레드는 스레드 이름을 나타냅니다. %%%%%% 5 문자 너비 %%%%%%%logger {50}은 로거 이름이 50 자임을 의미하며, 그렇지 않으면 그 기간에 따라 나뉘어집니다. %msg : 로그 메시지, %n은 라인의 변화입니다-> <layout> <패턴> %d {yyyy-mm-dd hh : mm : ss.sss} [ %스레드] %-5level %logger {50}- 비 -> <appender name = "ApplogAppender"> <concoding> UTF-8 </encoding> <!-지정된 로그 파일의 이름-> <파일> $ {log_home}/$ {appName} .Log> <롤링시, RollingFileAppender의 동작에는 파일 움직임이 포함되며 TimeBasedRollingPolicy를 이름 바꾸므로 시간에 따라 롤링 전략을 공식화합니다. -> <RollingPolicy> <!-롤링 중에 생성 된 파일의 스토리지 위치 및 파일 이름 {yyyy-mm-dd} : 롤링-> <filenamepattern> $ {log_home}/$ {. AppName}-%d {yyyy-mm-dd}-%i.log </filenamepattern> <!-선택적 노드, 예약 아카이브 파일을 제어하여 수량이 수량을 초과하는 경우 가장 큰 컨트롤, 이전 파일을 삭제하십시오. 매일 롤링되고 Maxhistory가 365라고 가정하면 이전 365 일 파일 만 이전 파일을 삭제하기 위해 저장됩니다. 이전 파일은 삭제되며 아카이브 용으로 생성 된 디렉토리도 삭제됩니다. -> <maxhistory> 365 </maxhistory> <!-로그 파일의 크기는 maxFilesize를 초과하고, 위에서 언급 한%에 따라 로그 파일은 구성 크기 basedtricgepolicy에주의를 기울여야합니다 TimeBasedFilenamingandtriggeringPolicy> <MaxFilesize> 100MB </maxFilesize> </timebasedFilenamingan dtriggeringPolicy> </RollingPolicy> <!-로그 출력 형식 :%D는 날짜 시간을 나타내고,%스레드는 스레드 이름,%-5 라벨을 나타냅니다. 왼쪽 디스플레이 5 문자 너비%로거 {50}은 로거 이름이 50 자임을 나타냅니다. 그렇지 않으면 기간에 따라 나뉘어집니다. %MSG : 로그 메시지, %N은 라인의 변화입니다.> <라이 아웃> <패턴> %d {yyyy-mm-dd hh : mm : ss.sss} [ %스레드]-[ %-5level] [ %logger {50} : %line]- %msg %n </pattern </layout> </appender> <!- 로그는 주로 로그 유형과 레벨 이름을 정의 할 수 있습니다. 패키지 레벨의 전반부 : 추적 <debug <info <warn <오류 추가 : rootlogger가 출력을 위해 구성된 appender를 사용하는지 여부 : false : 이는 현재 로거의 애플 렌더는 -ref, true : 현재 로거 레프의 Appender-Ref 및 Rootlogger가 효과적입니다. 및 Rootlogger-Refs는 효과적입니다. = "오류" /> <! <! "level ="info "additivity ="true "> <ppender-ref ref ="applogappender> < /logger> <!-루트와 로거는 아버지와 아들의 관계입니다. 특별한 정의가 없다면, 그것은 다음과 같습니다. 기본. 로거, 루트, 판단의 열쇠는이 로거를 찾은 다음이 로거의 apender와 레벨을 판단하는 것입니다. -> <root level = "info"> <ppender-ref = "stdout" /> <ppender-ref = "ApplogAppender" /> < /root> < /configuration>