이 글을 쓰게된 이유는 어느 순간 log 레벨을 무분별하게 사용하고 있는 나 자신에 대해서 보게 되었다. 그래서 공부도 할겸 찾아보고 정리하면서 내 머리 속에 넣기로 하였음
주요 목적은 시스템에서 반복되는 오류가 감지되는 경우와 같이 문제나 잠재적인 문제를 설명하는 메시지와 단순히 정보 제공하는 메시지를 분리
로그 수준은 필요한 정보만 기록되도록하고 생성된 로그의 양을 규제하는 방법이 있어야 한다. (스토리지 최소화)
Fetal
애플리케이션에서 가장 심각한 문제를 기록하기 위해 예약되어 있는 로그 수준이다. 일반적으로 데이터 손상이나 애플리케이션을 종료하기 직전에 기록됨
예시)
- 중요한 구성 정보가 누락 되었을 경우
- 핵심 애플리케이션 작업에 필요한 필수 외부 종속성 또는 서비스가 손실 됐을 경우
- 서버의 디스크 공간이나 메모미가 부족하여 애플리케이션이 중단되거나 응답하지 않게 되는 것
Error
특정 작업의 실행을 방해하는 애플리케이션 내의 오류 조건을 나타낸다. 앱의 기능이나 성능이 저하된 상태에서도 계속 작동할 수 있지만 error 로그는 즉시 조사해야 하는 문제를 나타냄
애플리케이션에서 발생하는 모든 오류나 예외가 error 수준에 기록되어야 하는 것은 아님.
- 예상된 동작일 경우
- 기능이나 성능이 저하되지 않는 경우
더 낮은 수준의 로그에 기록될 수 있다.
예시)
- 기능에 영향을 미치는 외부 API 또는 서비스 오류(복구 실패할 경우, 예를 들면 feignclient retry할 경우를 말하는 듯)
- 연결 시간 초과, DNS 확인 실패 등의 네트워크 통신 오류
- 시스템에서 리소스 생성 실패
- JSON 개체 디코딩 실패와 같은 예기치 않은 오류
Warn
일반적으로 예상치 못한 일이 발생했지만 애플리케이션은 정상적으로 계속 동작할 수 있을 경우 사용함
예시)
- 미리 정의한 임계값에 근접한 리소스 소비
- 애플리케이션이 큰 영향을 받지 않고 복구할 수 있는 오류
- 권장 사례와 일치하지 않는 오래된 구성 설정
- 외부 API 응답 시간이 허용 가능한 임계값을 초과한 경우
Info
애플리케이션이 정상적으로 동작하고 있음을 보여주기 위해 기록됨. 모든 사람이 애플리케이션의 정상 동작에 대한 요약을 볼 수 있도록 함
- “PENDING → “IN PROGRESS”로 작업 상태가 변경되는경우
- 예정된 작업이나 작업이 성공적으로 완료된 경우
- 서비스 또는 애플리케이션 구성요소를 시작 하거나 중지
- 애플리케이션 내의 중요한 이정표 또는 중요 이벤트 기록
- 장기 실행 프로세스 및 진행률 업데이트
- 시스템 상태 점검 또는 상태 보고서에 대한 정보
Debug
개발자가 디버깅 세션 중에 문제를 식별하는데 도움을 주는 수준의 로그 레벨
- 외부 API 호출 및 응답에 대한 세부정보
- 특정 작업 또는 메서드 실행 기간과 같은 타이밍 정보
참조 - https://betterstack.com/community/guides/logging/log-levels-explained/#2-error
'Server' 카테고리의 다른 글
CQRS 패턴 (0) | 2023.01.04 |
---|---|
Linux 프로세스, 메모리 사용량 확인 (1) | 2020.05.05 |