스프링 부트 활용

로깅

   로깅(Logging)이란 시스템 동작 시 시스템 상태/ 작동 정보를 시간의 경과에 따라 기록하는 것을 말하며, 그 기록을 로그(Log)라고 한다.

저장된 로그는 사용자의 패턴이나 시스템 동작 자체의 분석에 사용될 수 있으며, 해킹이나 침입 등의 사고가 발생한 경우 비정상 동작의 기록을 통해 추적을 수행할 수도 있다. 또한 내부 네트워크와 외부 네트워크 사이의 정보 흐름을 제어하는 방화벽에도 허가나 거부된 접근에 대한 로그가 기록되어 있다.

로깅 퍼사드 vs 로거

   스프링 부트에서 사용하는 로깅에 대해 알아보자. 스프링 부트은 기본적으로 Commons Logging을 사용하지만, 실제 사용단계에서는 SLF4j가 주로 사용된다.

Commons Logging과 SLF4j가 실제 로깅을 하는 것은 아니고 로거¹ API들을 추상화 해놓은 인터페이스이다. 이러한 인터페이스를 Loggin Facade라고 한다. 주로 프레임워크는 이렇게 Logging Facade를 사용해서 코딩을 한다. 개발자들도 애플리케이션을 만들 때 Logging Facade를 통해서 로거를 사용해도 문제 없다.

Logging Facade를 반드시 써야 할 필요는 없지만, Logging Facade의 역할은 하위에 있는 로거들을 바꿔 낄 수 있도록 해준다. 그래서 애플리케이션들이 자신이 원하는 로거로 쉽게 교체해서 사용할 수 있도록 해준다는 장점이 있다. 이러한 이유때문에 프레임워크들이 Logging Facade를 사용하는 것이다.
예를 들어 어떤 프레임워크에서 JUL²을 사용했다고 생각해보자. 그러면 이 프레임워크를 사용하는 모든 애플리케이션은 해당 로거를 쓰게 된다. 이러한 불편한 점을 없애고자 Logging Facade가 사용된다.

   Commons Logging은 한 때 런타임 시에 classpath / class loading과 관련된 문제, 메모리 누수 같은 많은 문제들이 있었다. 그래서 Commons Logging을 기피하는 움직임이 생겼고, 더 나아가서 SLF4j, Simple Logging Facade for Java, 라는 구조적으로 더 심플하고 안전한 새로운 라이브러리가 만들어졌다.
그런데 스프링 부트는 왜 다시 Commons Logging을 쓰는걸까? 스프링 프레임워크 코어가 만들어 질 때쯤 당시에는 SLF4j가 없어서 Commons Logging을 쓰고 있었고 자연스럽게 스프링 프레임워크는 Commons Logging을 사용하게 되었다.
스프링 부트 1.0 때는 SLF4j를 사용하기 위한 설정이 다 들어있었다. 코어에서 Commons Logging을 빼고 SLF4j를 끼워넣는 설정이 있었는데, 최근 스프링 5부터는 변화가 있었다. SLF4j를 사용하기 위해서 Spring-JCL³이라는 모듈을 만들었고 이 모듈은 컴파일 시점에 SLF4j나 Log4j2로 변경할 수 있는 기능을 가지고 있다.

Commons Logging은 런타임 도중에 클래스로더를 뒤지면서 로거를 찾는데, SLF4j는 컴파일 시점에 모든 의존성이 얽혀서 어떤 로거를 사용할 지 아미 결정이 난 상태로 뜬다.

결국 우리가 Commons Logging을 사용하더라도 SLF4j로 변경되고 SLF4j가 Logback을 선택하게 된다. 즉, 최종적으로 사용하는 로거는 Logback인 것이다.
스프링 부트 프로젝트를 생성하고 애플리케이션을 만들어서 실행했을 때 나오는 로그는 누가 찍은 것이냐라고 물어본다면 Logback이 찍었다가 정답이 된다.

의존성을 살펴보면 logging에 logback이 사용되고 jul을 사용하는 코드를 slf4j로 보내는 것을 확인 할 수 있다.

스프링 부트 로깅

   실제로 찍히는 로그를 보면서 기본 포맷과 특성을 알아보자.

▶ 로그 포맷

로그 설정에 의해서 찍히는 로그의 기본적인 포맷은 위에 나와있는 것과 같다.
순서대로 [날짜 | 시간 | 로그레벨 | PID | 쓰레드이름 | 풀 패키지 경로 & 클래스 이름 | 메세지]이다.

▶ 디버그 레벨 로그

   여기에 더 많은 로그, 예를 들어 디버그 레벨의 로그를 찍고 싶다면 애플리케이션 실행 시에 --debug나 -Ddebug 명령을 주면된다. (단, Embedded container, Hibernate, Spring Boot만)

모든 메세지를 다 디버깅 모드로 찍고싶다면 --trace를 사용하면 된다.

▶ 컬러 로그

   설정에 따라서 다르지만 로그가 전부 흰색으로 출력되는 경우가 있다. 이럴 떄 컬러로 로그를 출력하여 좀 더 보기 편하게 할 수 있다.
application.properties에 spring.output.ansi.enabled = true를 넣어주면 된다.

spring.output.ansi.enabled = true

▶ 로그 파일

   기본적으로 로그는 콘솔에만 출력이 되는데 로그를 파일로 출력하는 방법도 있다.
application.properties에 다음 프로퍼티 중에 자신이 사용하고자 하는 것을 작성하면 된다.

• logging.file.name : 로그 파일의 이름을 지정해서 생성. ex) logging.file.name = my.log
• logging.file.path : 로그 파일의 생성 위치를 지정. ex) logging.file.path = /var/log

logging.file.name의 경우 로그 파일의 이름을 자신이 원하는 이름으로 지정해서 임의의 위치에 생성된다. logging.file.path의 경우 spring.log라는 이름으로 파일이 생성되며 자신이 지정한 디렉토리 아래에 생성된다.

▶ 패키지 별 로그 레벨 설정

   패키지마다 로그의 레벨을 설정해 줄 수 있다. 이것 역시 properties를 사용한다. logging.level.[packagename] = [loglevel]과 같은 형식으로 작성하여서 사용할 수 있다.

logging.level.me.gracenam.springinit = DEBUG

▶ 로거 생성

   SLF4j를 사용해서 직접 로거를 생성해서 찍어줄 수 있다.

package me.gracenam.springinit;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;

@Component
public class SampleRunner implements ApplicationRunner {

    private Logger logger = LoggerFactory.getLogger(SampleRunner.class);

    @Autowired
    private GraceProperties graceProperties;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        logger.info("=================");
        logger.info(graceProperties.getName());
        logger.info(graceProperties.getFullName());
        logger.info("=================");
    }

}

Reference

• 스프링 부트 개념과 활용
• 공식 문서