[Log] 로깅의 개념과 다양한 로그 라이브러리, 그리고 주의사항

Apache Log4J

로깅(Logging)

1) 로깅이란?

운영 중인 웹 애플리케이션이 문제가 발생했을 경우, 문제의 원인을 파악하려면 문제가 발생했을 때 당시의 정보가 필요하다.

이런 정보를 얻기 위해서 Exception이 발생했거나, 중요 기능이 실행되는 부분에서는 적절한 로그를 남겨야 한다.

• 정보를 제공하는 일련의 기록인 로그(log)를 생성하도록 시스템을 작성하는 활동
• 프린트 줄 넣기(printlining)는 간단한, 보통은 일시적인, 로그를 생성하기만 한다.
• 시스템 설계자들은 시스템의 복잡성 때문에 로그를 이해하고 사용해야 한다.
• 로그가 제공하는 정보의 양은, 이상적으로는 프로그램이 실행되는 중에도, 설정 가능해야 한다.
• 일반적으로 로그 기록의 이점
  - 로그는 재현하기 힘든 버그에 대한 유용한 정보를 제공할 수 있다.
  - 로그는 성능에 관한 통계와 정보를 제공할 수 있다.
  - 설정이 가능할 때, 로그는 예기치 못한 특정 문제들을 디버그하기 위해, 그 문제들을 처리하도록 코드를 수정하여 다시 적용하지(redeploy) 않아도, 일반적인 정보를 갈무리할 수 있게 한다.

2) Log Level

1. trace : debug보다 세분화된 정보
2. debug : 디버깅하는데 유용한 세분화된 정보
3. info : 진행상황 같은 일반 정보
4. warn : 오류는 아니지만 잠재적인 오류 원인이 될 수 있는 경고성 정보
5. error : 요청을 처리하는 중 문제가 발생한 오류 정보

3) slf4J(Simple logging Facade For Java)

slf4J는 로깅 퍼사드(facade)로서 log4j, logback, commons-logging과 같은 로깅 프레임워크를 위한 추상화를 제공해준다.

예를 들어 log4j를 사용하다가 log4j2로 로깅프레임워크를 교체하면 많은 코드 수정이 발생한다. 이런 점을 고려하면 slf4j를 사용하고, log4j를 연결하여 사용하는 것이 바람직하다.

• logger를 bean으로 등록하여 사용하는 줄 알았는데 그렇게하지말고 logging이 필요한 클래스마다 Logger logger = LoggerFactory.getLogger(LoggingSample.class) 를 멤버로 선언해주고 사용하자.

4) log4j, log4j2, logback, commons-logging?

간단하게 시간 순서대로 비교하면 log4j, logback, log4j2 순서로 등장했다. 그러니까 log4j2가 상대적으로 최근에 등장한 로깅 프레임워크. logback과 log4j2는 log4j를 기반으로 하고 있어서 설정하는 방법이나 사용 방법이 유사하다.

1. log4j : Apache의 log4j는 꽤 오래된 로깅 프레임워크이다. 2015년에 개발팀의 log4j 개발 중단 발표가 있었다. 이제는 새 프로젝트에 적용하려면 다른 로깅 프레임워크를 사용해야한다.
2. logback : log4j를 구현한 개발자가 logback을 개발. log4j와 유사하면서도 향상된 성능과 필터링 옵션을 제공하며 slf4j도 지원. 그리고 참 편리한 자동 리로드도 가능하다.
   • 자동리로드란? : 설정파일의 에서 scan속성을 true로 설정하게 되면 설정이 변경시 자동으로 변경된 설정을 다시 로드하게 된다.
3. log4j2 : log4j2는 앞서 살펴본 log4j와 logback과 비교했을 때 가장 최근에 등장. logback과 동일하게 자동 리로드 기능과 필터링 기능을 제공한다.

그래서?

단순하게 비교만 해본다면 가장 최신(최신이라고 항상 좋은 것은 아니지만)이자 빠르며 logback의 아키텍처에서 발생하는 문제점을 수정한 이라고 Apache가 소개하는 log4j2를 권장!

Apache에 따르면 멀티 스레드 환경에서의 비동기 로거(Async Logger)의 경우 log4j 1.x 및 logback보다 몇 배나 되는 처리량을 보인다고 한다. 그리고 람다 표현식과 사용자 정의 로그 레벨도 지원해준다!

slf4j + log4j2쓰자!

5) 사용할 로그 레벨 (간소화)

1. FATAL : 이미 종료가 되는 시점의 FATAL 로그는 다양한 원인으로 작성되지 않을 확률이 다분. 따라서 반드시 필요한 경우가 아니면 사용하지 않는다. ERROR레벨로 대체.
2. ERROR : 예상/의도하지 않은 오류를 핸들링하는 시점에 사용. 로그 확인 시 ERROR 위주로 확인한다면 의도하지 않은 경우만 존재하기 때문에 빠르게 장애 원인 파악이 가능.
3. WARN : 동작에는 문제 없지만 이상 발생 가능한 경우. 알람을 제공할 정도의 문제는 아니므로 INFO레벨로 대체한다.
4. INFO : ERROR와 반대로 명확한 의도가 있는 로그들이 모두 INFO 레벨. 시나리오 상 의도된 Exception이라면 ERROR 레벨로 작성할 이유가 전혀 없다. Exception을 오류라고 생각하면 그럴 수도 있지만 Exception은 ‘예외’이기 때문에 의도한 경우에는 INFO로 적는 것이 더 좋다고 생각
   • 서비스, 도메인의 시나리오 상태 (동작 확인 용도)
   • 서비스, 도메인의 지표 (지표 측정 용도)
5. DEBUG : 개발 도중 확인을 위해 필요한 모든 로그들이 해당되는 레벨.
6. TRACE : 개발 시에 필요. 이또한 DEBUG레벨로 대체 가능.

6) 로그 작성 시 주의사항

1. 로그파일/DB 생명주기 & 저장소 용량
2. 개인정보
3. 시스템 주요 정보 (시스템 보안, 계정 정보)

• 로그가 저장되는 저장소의 용량, 파일 혹은 DB라도 삭제는 언제할 것인지? 이러한 계획을 명확하게 수립하고 운영해야 디스크 용량 부족과 같은 갑작스러운 장애를 방지할 수 있다.
• 로그에 개인정보, 시스템 계정 정보가 작성되는 경우가 많기에 주의할 필요함.

7) Log4J2

LOGGER/APPENDER/ENCODER?

• Logger : 실제 로깅을 수행하는 구성요소로 Level 속성을 통해서 출력할 로그의 레벨을 조절할 수 있다.
• Appender : 로그 메시지가 출력될 대상을 결정하는 요소
• Encoder : Appender에 포함되어 사용자가 지정한 형식으로 표현 될 로그메시지를 변환하는 역할을 담당하는 요소

Appender

• ConsoleAppender : 콘솔에 로그를 어떤 포맷으로 출력할지를 설정할 때 사용한다.
• FileAppender : 파일에 로그를 어떤 포맷으로 출력할지를 설정한다.
• RollingFileAppender: 로그의 양이 많아지면, 하나의 파일로 관리하기 어려워지는 경우가 생긴다.
  이런 문제를 해결하기 위해 하루 단위로 로그를 관리하고자 할 경우 사용된다.