만들어진 순서는 Log4j -> Logback -> Log4j2이다

0. slf4j

“SLF4J“는 “로깅 구현체“라기 보다는 “Logging Facade” 이다.
SLF4J는 로깅 Facade이다. 로깅에 대한 추상 레이어를 제공하는것이고 java로 따지면 interface덩어리 라고 볼 수 있다. (artifact이름도 api)

“일명 창구 일원화” 패턴인데, “SLF4J“의 API를 사용하면, 구현체의 종류와 상관없이 “일관된 로깅 코드“를 작성할 수있으며, “Apache Commons Logging“를 사용하다가 “Log4J“로 변경을 할 경우 최소한의 수정으로 구현체를 교체 할수 있다.

slf4j는 facade 패턴을 적용한 로깅 프레임워크다. facade 패턴은 인터페이스와 비슷한 역할이라 할 수 있다. slf4j와 함께 개발자는 원하는 로깅 라이브러리를 선택해 사용하면 된다. 따라서 slf4j를 사용한다면 개발하면서 로깅 라이브러리 변경이 필요한 경우 쉽게 교체가 가능하다.

출처: https://goddaehee.tistory.com/45

1. Log4j (Log for Java)

Logger(Category) : Log4J 에서 지원하는 핵심 클래스로서, 로깅이 일어나는 부분을 그룹화해, 필요한 그룹의 로그만을 출력하거나, 카테고리에 우선순위를 부여함으로써, 여러가지 출력 방법을 지원한다. 실제 로그 기능을 수행하는 역할을 담당한다.

Log4j의 로깅 레벨 (지정한 것 이상의 레벨메시지가 출력)

① FATAL : 가장 크리티컬한 에러가 일어 났을 때 사용한다.
② ERROR : 일반 에러가 일어 났을 때 사용한다.
③ WARN : 에러는 아니지만 주의할 필요가 있을 때 사용한다.
④ INFO : 일반 정보를 나타낼 때 사용한다.
⑤ DEBUG : 일반 정보를 상세히 나타낼 때 사용한다.
⑥ TRACE : 경로추적을 위해 사용한다.

장점
1. 프로그램의 문제 파악이 용이하다.
2. 빠른 디버깅 가능하다.
3. 로그 파악이 쉽다
4. 로그 이력을 파일, DB등으로 남길 수 있다.
5. 효율적으로 디버깅이 가능하다

단점
1. 로그에 대한 디바이스(파일) 입출력으로 인해 런타임 오버헤드가 발생한다.
2. 로깅을 위한 추가 코드로 인해 전체 코드 사이즈가 증가한다.
3. 심하게 생성되는 로그는 혼란을 일으킬 수 있다.
4. 심하게 생성되는 로그는 어플리케이션 성능에 영향을 미칠 수 있다.
5. 개발 중간에 로깅 코드를 추가하기 어렵다.

2. Logback

log4j를 토대로 새롭게 만든 Logging 라이브러리다.

slf4j를 통해 연관 라이브러리들이 다른 logging framework를 쓰더라도 logback으로 통합할 수 있다.

장점
1. log4j보다 약 10배 정도 빠르게 수행되도록 내부가 변경되었으며, 메모리 효율성도 좋아졌다.
2. log4j때부터 광범위한 테스트를 진행한 경험을 가지고 있으며, logback은 더욱 높은 레벨의 테스트를 통해 검증되었다.
3. 문서화가 잘 되어 있다.
4. 설정 파일을 변경하였을 경우, 서버 재기동 없이 변경 내용이 자동으로 갱신된다.
5. 서버 중지 없이 I/O Faliure에 대한 복구를 지원한다.
6. RollingFileAppender를 사용할 경우 자동적으로 오래된 로그를 지워주며 Rolling 백업을 처리한다.

3. Log4j2

https://logging.apache.org/log4j/2.x/performance.html

logback과 동일하게 자동 리로드 기능과 필터리 기능을 제공합니다. logback과 차이점은 Apache에 따르면 멀티 쓰레드 환경에서 비동기 로거(Async Logger)의 경우 Log4j 1.x 및 Logback보다 처리량이 18배 더 높고 대기 시간이 훨씬 더 짧다. 아래 그래프에서 성능 차이를 확인 해볼수 있다. 그리고 람다 표현식과 사용자 정의 로그 레벨도 지원합니다.