T-note

[티노트] 로깅

j9972 2024. 3. 28. 23:41
728x90

Logging

정보를 제공하는 일련의 기록인 로그를 생성하도록 시스템을 작성하는 활동.

우리는 왜 로깅을 사용할까?

  • 복잡한 시스템의 구조를 이해를 위함
  • 버그에 대한 정보 제공
  • 성능에 관한 통계와 정보 제공

 

로그 출력

  • System.out.println()
  • 로깅 라이브러리 [ logback, log4j 등등 ]

2가지 방식이 있는데 우리는 로깅 라이브러리를 사용할 것입니다.

syste.out을 안쓰는 이유

  • 성능상 좋지 않다
    1. system.out.print(), system.out.println()은 내부적으로 write(), newLine()을 사용한다. 이는 내부적으로 synchronized를 이용해 구현되어 다른 스레드들의 접근이 불가하여 성능을 낮춘다.
    2. 시스템 콜 호출 과정에서 블로킹으로 호출하기 때문이다
  • 로그들을 파일, DB, 클라우드 로그 저장소에 저장하기 적합하지 않다.

 

로깅을 테스트 해야하는가?

  • 로깅이 애플리케이션의 식별할 수 있는 동작인가? 아니면 구현 세부사항인가? 구분해야한다

→ 개발자만 보는 구현 세부 사항이면 괜찮지만, client 또는 개발자 이외 다른 사람이 보는 것이라면 식별할 수 있는 동작이므로 테스트 해야한다

지원 로깅 : 지원 담당자나 시스템 관리자가 추적할 수 있는 메시지를 생성한다. ( 비즈니스 요구사항 ) 진단 로깅 : 개발자가 애플리케이션 내부 상황을 파악할 수 있도록 돕는다

 

로깅은 얼마나 많은면 충분한가?

  • 지원로깅은 비즈니스 요구 사항이므로 조절을 할 수는 없지만, 진단 로깅은 가능하다
  • 진단로깅은 과도하게 사용하면 좋지 않다.
    1. 코드가 혼잡해진다. 특히 도메인 모델에 해당한다.
    2. 핵심은 로그의 신호 대비 잡음 비율인데, 로그가 많으면 정보 찾기가 힘들어진다.
  • 도메인 모델에서는 진단 로깅을 절대 사용하지 말기.
    • 디버깅시에만 사용하고 이후에 제거하기
    • 처리되지 않는 예외에 대해서만 사용

 

프로젝트에서 로깅 컨벤션

  1. 진단 로깅은 테스트 하지말고 지원 로깅은 테스트 하기
  2. 지원 로깅은 비즈니스 요구 사항이므로 코드베이스에 명시적으로 반영하기
  3. 진단 로깅은 과도하게 사용하지 말기