[Logging] slf4j, log4j, logback, log4j2

Logging

프로그램 개발 중이나 완료 후 발생할 수 있는 오류에 대해 디버깅하거나 운영 중인 프로그램 상태를 모니터링 하기 위해 필요한 정보(로그)를 (콘솔, 파일, 데이터베이스 등에) 기록하는 것.

장점: 전체적인 app의 흐름이나 타이밍 error도 확인할 수 있다는 장점이 있다.
단점: 출력문이 들어가기 때문에 응용 프로그램 속도를 늦출 수 있고, 너무 장황해질 수 있다.(하지만 메시지 level을 나눌 수도 있다.)

Java의 주요 Logging Framework

Log4J: 몇 년 전까지 사실상 표준이었음
Logback: Log4J 개발자가 만든 Log4J 후속 버전. 현재 많은 프로젝트에서 사용되고 있다
SLJ4J: Log4J 또는 Logback과 같은 백엔드 Logger Framework의 facade pattern

SLF4J(Simple Logging Facade for Java)

log4j 또는 Logback과 같은 백엔드 Logger Framework의 facade pattern. 다양한 로깅 프레임워크에 대한 추상화레이어를 제공하는 interface의 모음이다. 추상 로깅 프레임워크이기 때문에 단독으로 사용하지 않는다. SLF4J api를 사용하면 구현체의 종류에 상관없이 일관된 로깅 코드를 작성할 수 있다. (로깅 프레임워크를 변경해도 코드를 변경하지 않아도 됨)

slf4j가 인터페이스이고 log4j, logback 이런것들이 구현체라고 생각하면 될듯!

배포할 때 원하는 Logging Framework를 선택할 수 있다.
- Ex) Logback/log4j - SLF4J - app
- 개발할 때, SLF4J api를 사용하여 로깅 코드를 작성한다.
- 배포할 때, 바인딩된 Logging Framework가 실제 로깅 코드를 수행한다.
- Logging Framework 간에 쉬운 전환이 가능하다.

SLF4J API (인터페이스)

로깅에 대한 추상 레이어(인터페이스)를 제공. 즉 로깅 동작에 대한 역할을 수행할 추상 메서드를 제공. 사용자가 이 interface를 통해 로깅 코드를 작성한다.

slf4j-api-1.7.25.jar (2017년 기준) slf4j-api-1.8.0-beta2.jar (2019년 기준)

SLF4J 바인딩(.jar)

SLF4J 인터페이스를 로깅 구현체(Logging Framework)와 연결하는 어댑터 역할을 하는 라이브러리

class path에 사용하길 원하는 Logging Framework에 대한 SLF4J 바인딩(.jar)을 추가해야 한다. (반드시 한개만 사용 가능)
- 각각의 SLF4J binding(.jar)은 compile time에 오직 하나의 Logging Framework를 사용하도록 바인딩한다.
- class path에서 바인딩된 구현체가 발견되지 않으면 slf4j는 기본적으로 no-operation으로 설정되어 출력되는 것이 없다.
Logging Framework를 전환하려면 class path에서 slf4j 바인딩을 변경한다.
ex) SLF4J binding 종류
slf4j-log4j12-{version}.jar
- logback-classic-{version}.jar
- 등등

SLF4J Bridging Modules

(slf4j 이외의) 다른 로깅 API로의 Logger 호출을 SLF4J 인터페이스로 연결(redirect)하여 SLF4J API에 대한 호출인것처럼 하여 대신 처리할 수 있도록 하는 일종의 어댑터 역할을 하는 라이브러리

프로젝트는 다양한 components로 구성되고, 그 중 일부는 SLF4J 이외의 로깅 api에 의존하는 상황을 처리하기 위해 SLF4J에는 여러 Bridging Module이 제공된다.
다른 로깅 API -> Bridge(redirect) -> SLF4J API

참고 - facade pattern

여러 개의 클래스가 하나의 역할을 수행할 때, 대표적인 인터페이스만을 다루는 클래스를 두어 원하는 기능을 처리할 수 있게 도와주는 패턴이다.

클라이언트는 Facade에 요청을 전송하여 Subsystem과 통신하며, Facade는 해당 요청을 적절한 Subsystem 객체로 전달한다.
- Subsystem 객체가 실제 작업을 수행하지만 Facade는 인터페이스를 Subsystem 인터페이스로 변환하기 위해 자체 작업을 수행해야 할 수도 있다.
- 즉, 공통된 Interface를 적절하게 변환해서 연결한다.
Facade를 사용하는 클라이언트는 Subsystem 객체에 직접 액세스할 필요가 없고 실제 구현을 알 필요도 없다.

출처 - https://gmlwjd9405.github.io/2019/01/04/logging-with-slf4j.html

Logback vs Log4J vs Log4J2

log4j

콘솔로 출력하는 stdout 외에도 파일 출력도 제공
xml, properties로 환경을 구성할 수 있다.
2015년에 개발이 중단되었기 때문에 기존 시스템이 아니라면 사용할 이유가 없다

logback

log4j 이후, log4j2 전에 개발된 로깅 프로그램으로 log4j에서 향상된 성능과 필터링 옵션을 제공한다

slf4j의 구현체로써 동작함.
로그 레벨 변경 등에 대해 서버 재시작 없는 자동 리로딩을 지원한다.
Springboot 환경의 경우 Spring-boot-starter-web 안에 spring-boot-starter-logging의 logback이 기본적으로 포함되어 있어서 별다른 dependency 추가 없이 사용할 수 있다.

log4j2

가장 최신에 나온 로깅 프레임워크로 Apache의 log4j의 다음 버전이다.

logback과 동일하게 자동 리로드 기능과 필터링 기능을 제공한다.
logback과 가장 큰 차이점은 Apache에 따르면 멀티쓰레드 환경에서 비동기 로거(Async Logger)의 경우 Log4j 및 Logback보다 처리량이 훨씬(18배) 더 많고 대기 시간이 훨씬 짧다. 그리고 람다 표현식과 사용자 정의 로그 레벨도 지원한다.

출처 - https://minkwon4.tistory.com/161

dev-sian / meetings