원문 : https://docs.djangoproject.com/en/4.2/topics/logging/
파이썬 개발자들은 빠른 디버깅을 위해 print문을 자주 사용할 것이다.
logging 프레임워크를 도입하는 것은 매우 작은 노력이 들지만 훨씬 세련되고 유연한 이점을 제공한다. 디버깅 편의 뿐만 아니라 우리의 애플리이션의 상태와 헬스에 대한 일관되고 체계적인 정보를 제공해준다.
시작
Django는 파이썬의 내장 모듈인 logging을 확장한다.
구성 요소
파이썬 로킹 모듈은 아래 4개로 구성된다.
- Loggers
- Handlers
- Filters
- Formatters
Loggers
로거는 로깅 시스템의 도입점이다.
각 로거는 메시지를 처리하기 위해 쓸 수 있는 명명된 버킷입니다.
로거는 로그 레벨이 있으며, 로그 레벨이란 로거가 처리할 메시지들의 심각성을 나타낸다.
- DEBUG : 디버깅을 위한 저수준 정보
- INFO : 일반적인 시스템 정보
- WARNING : 마이너 문제들을 설명하는 정보
- ERROR : 메이저 문제들을 표현하는 정보
- CRITICAL : 심각한 문제들을 표현하는 정보
로거에 의해 기록되는 각 메시지들을 Log Record라고 부른다.
각 Log Record는 로그 레벨을 가지고 있다.
또한, Log Record는 발생한 이벤트에 대한 유요한 메타데이터를 포함할 수 있다.
메시지가 로거에 전달되고, 메시지의 로그 레벨과 로거의 로그 레벨을 비교한다.
메시지의 로그 레벨이 로거의 로그 레벨과 일치하거나 로거의 로그 레벨을 넘게 되면, 그 메시지는 추가 처리를 위한 작업에 돌입한게 된다.
그렇지 않으면, 그 메시지는 무시된다.
일단 로거가 메시지가 처리가 필요됨을 결정하고 판단하면, 그 메시지는 핸들러로 넘어간다.
Handlers
로거에서 각 메시지가 어떤 처리가 필요한지 결정하는 엔진이다.
화면이나 파일 또는 네트워크 소켓으로 메시지를 출력하는 등과 같이 특별한 로깅 액션을 정의한다.
로거와 마찬가지로, 핸들러 역시 로그 레벨이 있다.
Log Record의 로그 레벨과 핸들러의 로그 레벨이 맞지 않거나 초과하면, 핸들러 역시 해당 메시지를 무시한다.
로거는 여러 개의 핸들러를 가질 수 있다. 그리고 핸들러는 여려 개의 로그 레벨을 가질 수 있다. 이는 메시지의 중요도에 따라 다양한 형택의 알림을 제공할 수 있다.
예를 들어, 페이징 서비스에 ERROR와 CRITICAL 메시지를 발송하는 핸들러 하나를 만들 수 있으며, 두 번째 핸들러는 추후 분석을 위해 모든 로그들을 파일 형태로 처리하게 할 수도 있다.
Filters
A filter is used to provide additional control over which log records are passed from logger to handler.
필터는 Log Record가 로거에서 핸들러로 전달될 때, 추가 제어를 할 수 있게 하는 구성 요소다.
디폴트로 로그 레벨을 충족하는 모든 로그 메시지는 핸들러에서 처리된다.
하지만 filter를 설치함으로써, 로깅 프로세스 과정의 기준을 추가할 수도 있다.
예를 들어, ERROR 메시지를 특정 원본에서 다른 곳으로 보내기 위한 필터를 구축할 수도 있다.
또한 필터는 핸들러에 보내기 전에 메시지를 수정할 수 있게 한다.
예를 들어, 특정 조건이 충족된다면 ERROR 로그 레벨을 WARNING 로그 레벨로 변경 후 처리되게 할 수도 있다.
필터는 로거나 핸들러에 설치될 수 있다.
Formatters
Log Record는 최종적으로 텍스트 형태로 랜더링된다. 포멧터는 텍스트의 정확한 형태를 정의한다.
보안 이슈
로깅 시스템은 민감한 정보를 다룬다. Log Record web request 또는 stack trace와 같은 정보를 다루기도 하고, 보안 정보를 가지고 있는 데이터를 다루기도 한다.
AdminEmailHandler
내장 기능인 AdminEmailHandler는 보안과 관련되 내용이 담긴 정보를 다룬다. 메시지에 대한 모든 traceback을 보내는데, 지역변수와 장고 셋팅값들을 포함하는데, 쉽게 말해 DEBUG값이 True일 때 받는 정보와 동일하다.
따라서, 이메일을 통해 에러 메시지를 수신하는 방법은 권장하지 않는다.
써드파티를 사용하는 것을 권장한다. 그렇게 되면, 다양한 플랫폼으로 다양한 traceback과 누구에게 알림을 보낼지 시스템적으로 관리할 수 있다.
