고정 헤더 영역
상세 컨텐츠
본문
Log at the Proper Level
APM 혹은 SIEM을 운영하는 경우 Log Level은 알람을 보낼 때 기준으로 설정하는 값임을 인지한다. 예를들어:
- 5분안에 WARN 레벨의 로그가 15회 이상 발생한 경우, Slack으로 알림 발송
- 5분안에 ERROR 레벨의 로그가 5회 이상 발생한 경우, Slack으로 알림 발송
Log Level guide
- DEBUG 레벨 : 시스템의 동작들에 대한 자세한 정보
- INFO 레벨 : 예약된 작업, 시스템에 부하를 줄 수 있는 작업, 오래걸리는 작업 등
- WARN 레벨 : 잠재적인 오류로 간주할 수 있는 이벤트 (Timeout, Memory Usage, Fallback)
- ERROR 레벨 : 시스템에 문제가 발생하여 처리를 할 수 없는 경우
Write Meaningful Log Message
- 코드를 읽지 않고도 어떤 장애가 발생했는지 알 수 있는 수준의 로그를 작성한다.
- "An unhandled exception occured", "Transaction failed", "Request failed" 와 같은 메시지는 전혀 도움이 되지 않는다.
- "Transaction <transaction-type> failed: <failure-reason>", "Request <request-type> failed. retry after 5s: <inner-reason>" 와 같이 무엇을 실패했는지, 왜 실패했는지, 그래서 어떤 로직을 수행할 것인지 최대한 자세히 적어주는게 좋다.
- 로그 내부의 세부사항을 감추지 않는게 좋다.
- 추정되는 원인이나 해결할 수 있는 방법을 로그에 같이 기록한다.
Do not log about function itself
- 함수 본인에 대한 로그는 함수 내부에서 남기지 않는다. 예를들어:
- HTTP를 요청하는 함수 안에서 "failed to request http call" 와 같은 메시지는 남기지 않는다. 본인이 수행했던 영역에 대해서만 로그를 남긴다. ("failed to resolve dns", "tcp dial timeout", "timeout while reading body")
- 이후, 함수에 대한 로그는 함수를 호출한 곳에서 기록한다. ("http call for purchasing failed")
Log in Machine Parseable Format
- Structed logging을 사용하자. 추후 로그를 인덱스 잡기도 쉽다.
- Contextual logging을 함께 사용하여, 로그의 scope를 같이 파악할 수 있도록 만든다. (traceId 라고 한다)
- 예를들어: 어떤 request에서 어떤 어떤 동작들을 수행했는지 검색하면 알 수 있게끔 request_id를 같이 기록하자.
Think of Your Audience
로그를 보는 사람이 누군인지 중요하다. 예를들어:
- 개발자 본인이 될 수 도 있지만 같은 팀의 동료 개발자가 될 수 도 있다.
- 다른 팀의 동료 개발자가 보거나 운영 엔지니어가 볼 수 도 있다.
- 파트너 엔지니어가 볼 수도 있으며 On-premise 제품의 경우, 고객사의 운영 엔지니어가 볼 수 도 있다.
- 때로는 로그 메시지의 일부가 UI에 그대로 노출되어, 제품 사용자가 볼 수 도 있다.
https://www.dataset.com/blog/the-10-commandments-of-logging/
https://developer.atlassian.com/server/confluence/logging-guidelines/
