T-note
[티노트] 로깅
j9972
2024. 3. 28. 23:41
728x90
Logging
정보를 제공하는 일련의 기록인 로그를 생성하도록 시스템을 작성하는 활동.
우리는 왜 로깅을 사용할까?
- 복잡한 시스템의 구조를 이해를 위함
- 버그에 대한 정보 제공
- 성능에 관한 통계와 정보 제공
로그 출력
- System.out.println()
- 로깅 라이브러리 [ logback, log4j 등등 ]
2가지 방식이 있는데 우리는 로깅 라이브러리를 사용할 것입니다.
syste.out을 안쓰는 이유
- 성능상 좋지 않다
- system.out.print(), system.out.println()은 내부적으로 write(), newLine()을 사용한다. 이는 내부적으로 synchronized를 이용해 구현되어 다른 스레드들의 접근이 불가하여 성능을 낮춘다.
- 시스템 콜 호출 과정에서 블로킹으로 호출하기 때문이다
- 로그들을 파일, DB, 클라우드 로그 저장소에 저장하기 적합하지 않다.
로깅을 테스트 해야하는가?
- 로깅이 애플리케이션의 식별할 수 있는 동작인가? 아니면 구현 세부사항인가? 구분해야한다
→ 개발자만 보는 구현 세부 사항이면 괜찮지만, client 또는 개발자 이외 다른 사람이 보는 것이라면 식별할 수 있는 동작이므로 테스트 해야한다
지원 로깅 : 지원 담당자나 시스템 관리자가 추적할 수 있는 메시지를 생성한다. ( 비즈니스 요구사항 ) 진단 로깅 : 개발자가 애플리케이션 내부 상황을 파악할 수 있도록 돕는다
로깅은 얼마나 많은면 충분한가?
- 지원로깅은 비즈니스 요구 사항이므로 조절을 할 수는 없지만, 진단 로깅은 가능하다
- 진단로깅은 과도하게 사용하면 좋지 않다.
- 코드가 혼잡해진다. 특히 도메인 모델에 해당한다.
- 핵심은 로그의 신호 대비 잡음 비율인데, 로그가 많으면 정보 찾기가 힘들어진다.
- 도메인 모델에서는 진단 로깅을 절대 사용하지 말기.
- 디버깅시에만 사용하고 이후에 제거하기
- 처리되지 않는 예외에 대해서만 사용
프로젝트에서 로깅 컨벤션
- 진단 로깅은 테스트 하지말고 지원 로깅은 테스트 하기
- 지원 로깅은 비즈니스 요구 사항이므로 코드베이스에 명시적으로 반영하기
- 진단 로깅은 과도하게 사용하지 말기