Spring 로깅 log4j2

안녕하세요.

오늘은 프로젝트 진행중 logging하며 공부했던 내용을 정리 해보겠습니다.

 

logging의 목적은 프로그램 동작중 어떤 상황에 어떤 일이 발생했을 때 그 일을 logging level로 분류하여 나중에 그 정보를 바탕으로 추적을 하거나 오류 상황을 다시 보기 위함등등 많은 이유가 있습니다. 

 

많은 사람들이 개발을 시작할때 System.out.println으로 데이터를 찍어보곤 하죠 하지만 이 메서드는 사용해선 안됩니다.

 

그 이유는 

 

이런식으로 내부에 synchronized를 사용하고 있기 때문입니다. 

synchronized를 사용하면 락을 걸어 다른 스레드의 접근을 막고 한 개의 스레드만 동작하게됩니다. 

멀티쓰레딩 환경에서 무분별한 동기화의 성능 저하의 원인이 될 수 있습니다.

 

그래서 System.out.println보단 logger를 사용해야하는데 

 

Spring에서 logger의 종류도 다양한데 저는 그중 log4j2를 사용하겠습니다. 

로거의 종류별 성능 측정 지표나 관련해서 정리된 자료가 많으므로 참고하시면 되겠습니다.

 

Spring에서는 이미 추상화를 잘 해두어 가져다 사용하면 되는 것들이 많죠,

logger도 해당이 되는데 어떤 logger 구현체를 가져다 끼워도 동작할 수 있도록 slf4j라는 추상체가 이미 있습니다. 

따라서 Spring에서는 다음 처럼 설정을 하고 

 

 

 

@slf4j라는 애너테이션을 사용하여 구현체 logger를 사용할 수 있습니다.

Sping boot start web에는 이미 logger가 적용되어 있는데 저는 log4j2를 사용할 것 이므로 여기서는 default logging을 제외 시켰습니다.

 

log4j2는 사용을 위해 xml설정(원한다면 yml로 변경 가능) 후 사용하게 되는데요 이 xml에 설정하는 속성에 대한 설명은 최범균님의 log4j 글에 자세히 나와 있습니다.

(https://javacan.tistory.com/entry/9)

 

이런식으로 @Slf4j 애너테이션을 붙여서 설정한 logger 구현체를 사용이 가능한데요

이 @Slf4j 애너테이션을 들여다보면

 

 

해당 애너테이션이 여러 로거 클래스에 대해서도 유효하다고 나와있습니다.

 

그래서 이런 위와 같이 애너테이션을 붙인 후 

이렇게 log를 바로 사용이 가능한데요 

이 log에는 log level이라는게 존재합니다.

 

위에서 제가 warn으로 로깅을 남긴 이유는  저장된 이미지 삭제 시도에 예외가 발생해서 삭제가 안되어 이미지가 계속 누적되면 서버의 자원을 누적해서 계속 잡아 먹을 가능성이 있으므로 그런 미래에 상황에 대해 경고를 주고자 warn level 로 지정하였습니다.

 

이 log level은 

 

TRACE < DEBUG < INFO < WARN < ERROR < FATAL 순으로 하위 범위를 포함하게 됩니다. 

 

하위 범위를 포함한다는 뜻은 DEBUG로 로그를 찍게될 경우 INFO, WARN, ERROR, FATAL 까지의 로그가 찍히게 되고 ERROR로 로그를 찍게되면 ERROR, FATAL만 찍힌다는 의미입니다.

 

그러면 어느 상황에 어느 log level을 선택해서 사용해 될 까요?

 

FATAL은 심각한 에러로 인해 애플리케이션이 동작을 멈출 경우 찍는 것인데 애플리케이션이 동작이 멈출 경우 로그가 찍히지 않을 수도 있습니다.

 

ERROR는 요청을 처리하는 도중 문제가 생기는 경우에 찍는 log level이고 

 

WARN은 처리 가능한 문제, 향후 시스템 에러의 원인이 될 수 있는데 문제에 대한 경고로 사용됩니다. 

 

INFO는 정보성 메시지 , 이미 알고있는 혹은 예상되는 예외에 대해서 사용합니다.

 

DEBUG는 디버깅 하기위한 정보 지정을 위해 사용하고 

 

TRACE는 DEBUG보다 조금 더 자세한 정보를 보여주게됩니다.

 

이렇게 log level 사용 용도를 보시면 제가 위에서 warn을 사용한 이유가 이해 되실 겁니다.

 

 

빠이