머리말
오늘 따라 봄 부팅 로그 logback을 구성하는 방법을 소개, 난 그냥 배운, 당신에 대해 어떻게 데이터를 확인하려면 다음 질문입니다
- 어떻게 로그를 소개합니다?
- 어떻게 출력 형식 및 출력 구성을 로그에?
- 어떻게 코드를 사용하는 방법?
본문
봄 부트는 모든 내부 로그에 사용 커먼즈 로깅 ,하지만 기본 구성은 같은 공통 로그에 대한 지원을 제공 : 자바 백분율 로깅 , Log4J를 , Log4J2 및 Logback . 각 로거 구성을 통해 콘솔 출력 로그 파일이나 콘텐츠를 사용할 수 있습니다.
기본 로그 Logback
SLF4J는 외관에 대한 로깅 --simple 자바 , 그것은 로그인 자바의 모든 유형을위한 통합 프레임 워크입니다 외관 초록. 일반적으로 사용되는 - 대부분의 자바 프레임 워크를 로깅 java.util.logging, log4j, logback, commons-logging, API (JCL)를 로깅 자카르타 커먼즈를 사용하여 스프링 프레임 워크. SLF4J는 균일 한 로그 추상적 인 인터페이스를 정의하고, 실제 로그 실현은 런타임에 결정된다 -이 로그의 모든 유형에 대한 바인딩 프레임 워크를 제공합니다.
Logback는 동안 자연 지원 SLF4J, 그것은 운영 환경의 많은에 적응할 수, 더 효율적입니다, 개발의 로깅 프레임 워크의 log4j 프레임 워크의 새로운 세대입니다.
기본적으로, 봄 부팅 Logback은 로그인하고 정보 수준 콘솔에 사용됩니다. 당신은 응용 프로그램과 다른 예제를 실행하면 정보 수준 로깅을 많이 볼 수 있어야합니다.
다음과 같이 그림에서 로그 출력 콘텐츠 요소를 볼 수있다 :
- 날짜 시간 : 정확한 밀리 초
- 로그 수준 : ERROR, WARN, INFO, DEBUG 또는 TRACE
- 프로세스 ID
- : 구분은
---실제 로그의 시작을 식별 - 스레드 이름 : 대괄호 (콘솔 출력이 절단 될 수있다)
- 로거 이름 : 일반적으로 사용되는 소스 클래스 이름
- 로그 내용
로그인 의존성 추가
추가 종속성 받는다는 스프링 부팅 스타터 로깅 경우 :
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</dependency>
그래서, 우리의 봄 부팅 응용 프로그램이 자동으로 애플리케이션 로깅 프레임 워크, 봄 부팅 시작, 초기화로 logback 사용하고 org.springframework.boot.logging.Logging - 응용 프로그램 리스너에 의해 상황에 따라 사용됩니다.
그러나, 우리는 실제 개발에 직접 종속성을 추가하지 않아도, 당신은 스프링 부팅 스타터 로깅을 포함 스프링 부팅 스타터를 찾을 것, 내용이 봄 부팅 기본 로깅 프레임 워크 logback에 따라 달라집니다. 블로거의 예는이 프로젝트가 Thymeleaf에게 유용한 프로젝트 중 하나를 기반으로하고, Thymeleaf 봄 부팅 시동기를 포함 의존되고, 결국 난 그냥 소개 Thymeleaf이 될 수 있습니다.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>특히도 알 수있다.
기본 구성 등록 지원
종속성이 클래스 경로 현재 응용 프로그램의 추가로 봄 부팅 스프링 부팅 선발 로깅으로 너무 오래, 기본 로그 구성의 많은 우리를 제공한다 "밖으로 상자."
여기 application.properties 로그에 어떤 관련 속성을 구성 할 수 있습니다.
콘솔 출력
TRACE으로 로우에서 하이로 로깅 수준 <DEBUG <INFO는 <<WARN ERROR <FATAL는 경고를 설정하면, 정보 출력 WARN보다 낮을 수 없다.
봄 부팅 기본 구성 ERROR, WARN그리고 INFO콘솔에 로그 출력의 레벨입니다. 또한, Jieke 두 가지 방법 (오픈 권고를 개발할 때) 응용 프로그램 -debug 플래그를 시작하여 "디버그"모드를 활성화 할 수 있습니다 :
- 실행 한 후 명령에 추가
--debug등의 증상 :$ java -jar springTest.jar --debug - 에서
application.properties구성debug=true속성이 true로 설정되어, 핵심 로거 출력이 더있을 것입니다 (포함 된 컨테이너를 포함하는이, 봄, 최대 절전 모드),하지만 자신의 응용 프로그램 로그 및 DEBUG 수준에 출력을하지 않습니다.
파일 출력
기본적으로, 봄 부팅되지 로그 파일에 콘솔에 로그 출력. 콘솔 출력 이외의 로그 파일을 작성하려는 경우에 application.properties에 logging.file 또는 logging.path 속성을 설정해야합니다.
- logging.file, 설정 파일 절대 경로 또는 상대 경로 일 수있다. 예를 들면 :
logging.file=my.log - logging.path, 디렉토리는 디렉토리 spring.log 파일에 생성 설정하고 다음과 같은 로그의 내용을 작성 :
logging.path=/var/log
단지 logging.file 경우, xxx.log 프로젝트의 현재 경로에 로그 파일을 생성합니다.
단지 logging.path 경우의 / var / 로그 파일 spring.log을 생성하는 폴더를 기록
사용할 수없는 모두 사용해야 만 logging.file 적용 참고 :
기본적으로는, 로그 파일의 크기가 한 번 10메가바이트 포인트에 도달 잘라 새 로그 파일이 생성됩니다, 기본 수준은 다음과 같습니다 ERROR, WARN, INFO
레벨 제어
레코드 레벨에서 지원하는 모든 로깅 시스템합니다 (application.properties에서 예) 봄 환경에서 설정 될 수
형식은 'Logging.level * = LEVEL.'
logging.level: 로그 레벨 제어 접두사는*패키지 이름 또는 로거의 이름입니다LEVEL: 选项 TRACE, DEBUG, INFO는, WARN ERROR, FATAL, OFF
예를 들면 :
logging.level.com.dudu=DEBUG:com.duduDEBUG 레벨 출력에 패키지 이하의 모든 클래스logging.level.root=WARN: 루트 로그 수준은 출력을 WARN
사용자 정의 로그 구성
로그 서비스는 일반적으로 ApplicationContext를 이전에 생성되기 때문에 초기화하고는 Spring 설정 파일에 의해 제어되지 않아야합니다. 따라서 여전히 잘 로그 제어 및 관리 시스템의 특성과 전통적인 봄 부팅 외부 설정 파일에 의해 지원 될 수있다.
로깅 시스템에 따라 파일 이름이 조직의 규칙에 따라 구성 할 수 있습니다 올바르게로드 할 수 있습니다 :
- Logback :
logback-spring.xml,logback-spring.groovy,logback.xml,logback.groovy - Laog4j :
log4j-spring.properties,log4j-spring.xml,log4j.properties,log4j.xml - Log4j2 :
log4j2-spring.xml,log4j2.xml - JDK (자바 백분율 로깅) :
logging.properties
봄 부팅 우선 순위 관계자는 함께 사용하는 것이 좋습니다 -spring(예 : 사용하는 등 로그 구성의 파일 이름 logback-spring.xml대신 logback.xml), 스프링 부팅 (일부 봄 부팅 관련 구성 항목이 추가 될 수있다라는 logback-spring.xml 로그 구성 파일을 ) 후술.
상기는 기본 명명 규칙, 그리고에 src/main/resources다음이 될 수 있습니다.
당신이 구성 로그를 완벽하게 제어를 원하지만 사용하지 않는 경우 즉 logback.xml로 Logback, 당신은 logging.config하여 사용자 정의 name 속성을 지정할 수 있습니다 구성 이름 :
|
|
일반 구성 파일의 이름을 변경 할 필요가 없습니다,하지만 당신은 다른 프로필 사용하여 다른 하루를 실행하려면 동안
구성 치,이 기능이 유용 할 것이다.
우리가 logback-spring.xml의 일반적인 예를 살펴 보자
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="60 seconds" debug="false">
<contextName>logback</contextName>
<property name="log.path" value="E:\\test\\logback.log" />
<!--输出到控制台-->
<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
<!-- <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>ERROR</level>
</filter>-->
<encoder>
<pattern>%d{HH:mm:ss.SSS} %contextName [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<!--输出到文件-->
<appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${log.path}</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>logback.%d{yyyy-MM-dd}.log</fileNamePattern>
</rollingPolicy>
<encoder>
<pattern>%d{HH:mm:ss.SSS} %contextName [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="info">
<appender-ref ref="console" />
<appender-ref ref="file" />
</root>
<!-- logback为java中的包 -->
<logger name="com.dudu.controller"/>
<!--logback.LogbackDemo：类的全路径 -->
<logger name="com.dudu.controller.LearnController" level="WARN" additivity="false">
<appender-ref ref="console"/>
</logger>
</configuration>루트 <configuration>속성이 포함되어 있습니다
- 검사 :이 속성을 true로 설정하면 프로파일 변경이 다시로드 될 경우, 디폴트 값이 true입니다.
- scanPeriod는 : 프로파일 모니터링 간격이 수정되는 경우 시간 단위가 주어지지 않은 경우, 기본 (밀리 초)을 설정합니다. 스캔이 true의 경우,이 속성이 적용됩니다. 기본 간격은 1 분입니다.
- 디버그 :이 속성을 true로 설정하면, 내부 로그 정보, 실시간보기 logback 실행을 logback 인쇄됩니다. 기본값은 false입니다.
루트 <configuration>자식 노드 : <configuration>두 가지 속성, 즉 세 개의 하위 노드의 총 다음
프로퍼티 : 컨텍스트 이름을 설정<contextName>
각 로거 로거 컨텍스트에 연관되어, 기본 컨텍스트 이름은 "기본"입니다. 그러나, 다른 명칭이 다른 기록 애플리케이션 사이를 구별하기위한 제공 사용될 수있다. 일단 설정되면, 로그가 콘텍스트 이름 %의 contextName 의해 인쇄 될 수 있고, 변경 될 수 없다.
|
|
속성 2 : 변수를 설정<property>
이름의 값이 변수의 값에 정의 된 변수 값의 값의 이름이고, 태그는 두 속성 이름과 값이있는 변수의 값을 정의하는 데 사용된다. 이것은 콘텍스트에 의해 정의 로거 값으로 삽입한다. 정의 된 변수를 만들 수 있습니다 후 "$를 {}"변수를 사용합니다.
|
|
아이 노드<appender>
펜더 출력 노드 로그 형식을 사용, 두 속성 이름과 클래스가, 클래스가있는 출력 정책을 지정하는 데 사용됩니다, 일반적으로 전술 콘솔 출력 및 파일 출력 정책을 사용합니다.
##### 콘솔 출력을 ConsoleAppender :
<!--输出到控制台-->
<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>ERROR</level>
</filter>
<encoder>
<pattern>%d{HH:mm:ss.SSS} %contextName [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<encoder>이 로그 코드를 나타냅니다 :
%d{HH: mm:ss.SSS}- 로그 출력 시간%thread- 프로세스 출력 웹 응용 프로그램에 유용 로그, 비동기 태스킹의 이름%-5level- 로그 레벨은 왼쪽으로 정렬 다섯 개 문자를 사용%logger{36}- 로그 수출의 이름%msg- 로그 메시지%n- 줄 바꿈 플랫폼
시스템 정의 인터셉터 ThresholdFilter, 예를 들어, 로깅의 레벨 파일로 출력되지 이하 ThresholdFilter 오차를 필터링하도록 사용된다. 당신이 주석으로 기억하지 않는다, 또는 로깅 콘솔을 찾을 수 있습니다 경우 ~
RollingFileAppender를 파일로 출력
점점 더 많은 시간이 로그가 점점 더 증가 할 것이다 실행하는 응용 프로그램과 파일에 대한 또 다른 일반적인 로그 출력은, 그들은 같은 파일로 출력이 좋은 생각이 아니다 될 것입니다. RollingFileAppender로그 파일을 공격 태도를 보여준 :
<!--输出到文件-->
<appender name="file" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${log.path}</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>logback.%d{yyyy-MM-dd}.log</fileNamePattern>
<maxHistory>30</maxHistory>
<totalSizeCap>1GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%d{HH:mm:ss.SSS} %contextName [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
것이 중요 어디 rollingPolicy정의, 위의 예는 <fileNamePattern>logback.%d{yyyy-MM-dd}.log</fileNamePattern>분할 패턴 로그를 정의 - 파일에 매일 아카이브 로그, <maxHistory>30</maxHistory>그것은 단지 전체 디스크 공간을 채우는에서 로그를 방지하기 위해 로그의 지난 30 일을 유지하고 있음을 나타냅니다. 마찬가지로, 사용될 수있다 %d{yyyy-MM-dd_HH-mm}로그 모드 세그멘테이션에 대한 정확한 지점을 정의. <totalSizeCap>1GB</totalSizeCap>로그 파일 크기 제한을 지정하려면, 예를 들어,이 값에, 그것은 이전 로그를 삭제 1 기가 바이트로 설정됩니다.
두 자식 노드<root>
필수 루트 노드가 가장 기본적인 로그 출력 레벨을 지정하는 데 사용되는 노드, 레벨에만 때문이다.
- 수준 : 인쇄를 설정하는 데 사용 수준, 대소 문자를 구별 : TRACE, DEBUG, INFO는, WARN , ERROR, ALL 및 OFF, 또는 동의어 NULL을 상속 설정할 수 없습니다.
기본값은 DEBUG입니다.
0 개 이상의 요소를 포함 할 수 있으며, 펜더이 loger에 추가됩니다 식별합니다. -
<root level="debug"> <appender-ref ref="console" /> <appender-ref ref="file" /> </root>
세 개의 자식 노드<loger>
<loger>하나 개의 특정 패킷 또는 특정 클래스 및 지정을 인쇄 할 로깅 수준을 설정하려면 <appender>. <loger>하나의 이름 속성, 옵션 수준 및 옵션 addtivity 속성입니다.
name: 특정 패킷을 지정하거나 특별히이 loger 특정 클래스에 구속.level: 인쇄의 수준을 설정하려면 케이스는 다음과 같습니다 TRACE는 DEBUG는 정보는, WARN, ERROR, ALL과 OFF가, 집행의 높은 수준을 대신하여, 일본의 인기 값 상속 동의어 또는 NULL이있다. 이 속성이 설정되어 있지 않은 경우, 현재 수준의 loger는 상관을 상속합니다.addtivity: 인쇄 정보가 더 높은 loger에 전달 여부. 기본값은 true입니다.
loger 때 실제 사용에 두 가지 경우가 있습니다
코드를 사용하는 방법을 찾기 위해
package com.dudu.controller;
@Controller
public class LearnController {
private Logger logger = LoggerFactory.getLogger(this.getClass());
@RequestMapping(value = "/login",method = RequestMethod.POST)
@ResponseBody
public Map<String,Object> login(HttpServletRequest request, HttpServletResponse response){
//日志级别从低到高分为TRACE < DEBUG < INFO < WARN < ERROR < FATAL，如果设置为WARN，则低于WARN的信息都不会输出。
logger.trace("日志输出 trace");
logger.debug("日志输出 debug");
logger.info("日志输出 info");
logger.warn("日志输出 warn");
logger.error("日志输出 error");
Map<String,Object> map =new HashMap<String,Object>();
String userName=request.getParameter("userName");
String password=request.getParameter("password");
if(!userName.equals("") && password!=""){
User user =new User(userName,password);
request.getSession().setAttribute("user",user);
map.put("result","1");
}else{
map.put("result","0");
}
return map;
}
}
이것은 우리가 로그 소개, 로그인을 판단하고, 로깅의 다양한 수준을 인쇄하는 방법은 다음 logback-spring.xml의 인쇄 로그 수준있어서 어떤 종류의 구성을 살펴.
먼저 :는 펜더를 loger 구성으로, 더 수준이 지정되지 않은 지정하지
|
|
<logger name="com.dudu.controller" />모든 클래스는 컨트롤러 패키지가 제어하는 로그를 인쇄하지만 인쇄 설정과 수준하지 않았다, 그래서 그의 상사는 수준 "정보"로그 상속,
설정하지 addtivity를, 기본이 참 인쇄이 정보가 더 높은 loger로 전송된다 ;
펜더 설정하지,이 loger 자체가 어떤 정보를 인쇄하지 않습니다. <root level="info">인쇄 루트 레벨이 "정보"로 설정되어, "콘솔"는 펜더에 이름을 지정합니다.
로그인 방법은 패키지에 com.dudu.controller.LearnController 클래스, LearnController의 com.dudu.controller을 수행 할 때, 먼저 실행 <logger name="com.dudu.controller"/>하지 않습니다 자체, 전송 레벨이 루트에 "정보"가 아닌 정보 "정보"더 큰 로그입니다, 인쇄;
펜더 프로세스 "콘솔"콘솔에 프린트 펜더 정보 구성 명 "콘솔"로 정보 전송, 루트 종속;
다음과 같이 인쇄 결과는 다음과 같습니다
|
|
두 번째 : 여러 구성 지정된 수준, 지정된 펜더와 loger
|
|
控制com.dudu.controller.LearnController类的日志打印，打印级别为“WARN”;
additivity属性为false，表示此loger的打印信息不再向上级传递;
指定了名字为“console”的appender;
这时候执行com.dudu.controller.LearnController类的login方法时，先执行<logger name="com.dudu.controller.LearnController" level="WARN" additivity="false">,
将级别为“WARN”及大于“WARN”的日志信息交给此loger指定的名为“console”的appender处理，在控制台中打出日志，不再向上级root传递打印信息。
打印结果如下：
|
|
当然如果你把additivity=”false”改成additivity=”true”的话，就会打印两次，因为打印信息向上级传递，logger本身打印一次，root接到后又打印一次。
多环境日志输出
据不同环境（prod:生产环境，test:测试环境，dev:开发环境）来定义不同的日志输出，在 logback-spring.xml中使用 springProfile 节点来定义，方法如下：
文件名称不是logback.xml，想使用spring扩展profile支持，要以logback-spring.xml命名
<!-- 测试环境+开发环境. 多个使用逗号隔开. -->
<springProfile name="test,dev">
<logger name="com.dudu.controller" level="info" />
</springProfile>
<!-- 生产环境. -->
<springProfile name="prod">
<logger name="com.dudu.controller" level="ERROR" />
</springProfile>
可以启动服务的时候指定 profile （如不指定使用默认），如指定prod 的方式为：
java -jar xxx.jar –spring.profiles.active=prod
关于多环境配置可以参考
动态配置日志输入文件目录：
可以对logback中的配置文件 log.path进行动态设置。
对项目进行打包的时候，可以通过maven 的-D 参数进行设置
多线程下的日志追踪（mdc）
MDC（Mapped Diagnostic Context，映射调试上下文）是 log4j 和 logback 提供的一种方便在多线程条件下记录日志的功能。某些应用程序采用多线程的方式来处理多个用户的请求。在一个用户的使用过程中，可能有多个不同的线程来进行处理。典型的例子是 Web 应用服务器。当用户访问某个页面时，应用服务器可能会创建一个新的线程来处理该请求，也可能从线程池中复用已有的线程。在一个用户的会话存续期间，可能有多个线程处理过该用户的请求。这使得比较难以区分不同用户所对应的日志。当需要追踪某个用户在系统中的相关日志记录时，就会变得很麻烦。
一种解决的办法是采用自定义的日志格式，把用户的信息采用某种方式编码在日志记录中。这种方式的问题在于要求在每个使用日志记录器的类中，都可以访问到用户相关的信息。这样才可能在记录日志时使用。这样的条件通常是比较难以满足的。MDC 的作用是解决这个问题。
MDC 可以看成是一个与当前线程绑定的哈希表，可以往其中添加键值对。MDC 中包含的内容可以被同一线程中执行的代码所访问。当前线程的子线程会继承其父线程中的 MDC 的内容。当需要记录日志时，只需要从 MDC 中获取所需的信息即可。MDC 的内容则由程序在适当的时候保存进去。对于一个 Web 应用来说，通常是在请求被处理的最开始保存这些数据。
使用：
java:
MDC.put("traceId", requestId);
pattern:
<pattern>%d{yyyy-MM-dd HH:mm:ss} %X{traceId} %-5level %logger{36} | %msg%n</pattern>
使用%X 获取traceId
filter：
对日志输出进行过滤，详见 https://www.cnblogs.com/drizzlewithwind/p/6045435.html
总结
到此为止终于介绍完日志框架了，平时使用的时候推荐用自定义logback-spring.xml来配置，代码中使用日志也很简单，类里面添加private Logger logger = LoggerFactory.getLogger(this.getClass());即可