[Server] 운영 환경을 위한 실용적인 로그 레벨(Practical Log Level)

 

1. 운영 환경을 위한 실용적인 로그 레벨(Practical Log Level)

---

[ 실용적인 로그 레벨(Practical Log Level) ]

먼저 개인적으로 서비스를 운영하면서 느꼈던 로그 레벨에 대한 부분을 표로 정리하면 다음과 같다.

	사용 환경	상황
DEBUG	개발	개발 중에 문제를 추적하고 진단하는 데 사용됨
INFO	개발, 운영	서비스를 운영하고 상황을 이해하는 데 사용됨
WARN	개발, 운영	잠재적인 문제나 주의가 필요한 상황을 알리기 위해 사용됨
ERROR	개발, 운영	시스템 오류나 예외 상황을 기록하기 위해 사용됨

 

 

관련 부분을 보다 자세하 살펴보면 다음과 같다.

•  DEBUG
  • 개발을 진행하면서 문제를 추적하고 진단하기 위한 개발 및 테스트용 로그
  • 주로 로직 검증, 버그 추적, 데이터 흐름 파악을 위해 사용되므로, 운영 환경에서는 남기지 않음
  • ex) log.debug("User data fetched: {}", userData);
• INFO
  • 서비스를 운영하면서 정상적인 동작을 기록하기 위한 정보성 로그
  • 비즈니스에 의한 상태 변경, 사용자의 활동 기록, 주요 이벤트의 시작과 종료 등을 기록하여 운영에 활용되므로, 운영 환경에서 필요함
  • ex) log.info("User {} logged in at {}", userId, loginTime);
• WARN
  • 잠재적인 문제나 주의가 필요한 상황을 알리기 위한 경고성 로그
  • 시스템의 안정성에 영향을 미칠 수 있는 상황을 미리 감지하고 대응하기 위해 사용되므로, 운영 환경에서 남김
  • ex) log.warn("Api Call failed for user {}: {}", userId, errorMessage);
• ERROR
  • 시스템 오류나 예외 상황을 기록하기 위한 심각한 로그
  • 서비스 장애, 데이터 손실, 보안 위협 등 즉각적인 조치가 필요한 상황을 기록하므로, 운영 환경에서 반드시 남김
  • ex) log.error("Database connection failed: {}", exceptionMessage);

 

 

대부분의 수준은 직관적으로 이해할 수 있겠지만, WARN과 ERROR의 차이는 모호하다고 느끼는 경우가 많아 살펴볼 필요가 있다. WARN은 잠재적인 문제를 알리는 반면, ERROR는 실제로 문제가 발생했음을 나타낸다. 예를 들어, API 호출 실패가 일시적인 네트워크 문제로 인해 발생했다면, WARN으로 기록하고 재시도 처리를 하면 된다. 하지만 데이터베이스 연결 실패와 같이 서비스 운영에 직접적인 영향을 미치는 문제는 ERROR로 기록해야 한다.

따라서 이 둘은 개발자가 가져야 하는 인식에도 차이가 있다. 일반적으로 WARN 로그는 에러의 발생 빈도를 바탕으로, 다소 느슨한 특정 임계치를 넘었을 경우 개발자에게 인지를 주어야 한다. 예를 들어 동일한 WARN 로그가 1분 동안 100건 이상 발생한다면, 잠재적 문제 상황임을 가정하고 개발자에게 노티를 주는 것이다. 반면 ERROR 로그는 이미 에러가 발생하는 상황이기 때문에, 1건이라도 발생 시에 혹은 다소 엄격한 임계치인 100건 중 5건 이상 발생 시에 개발자에게 알림이 가도록 설정할 필요가 있다. 개발자에게 알림을 주기 위해 페이저 듀티(PagerDuty) 같은 온콜 시스템과도 연동할 수 있다. 이를 통해 문제 상황이 감자된다면, 개발자의 연락처로 전화나 메신저로의 알림 등을 자동화할 수 있다.

 

 

WARN과 ERROR 로그에 대해 각각 다른 임계치로 알림을 설정하는 것이 좋다. 또한 슬랙(Slack)과 같은 메신저 채널에서는 ERROR 로그 알림을 일단 받아두어 손쉽게 접근하여 인지할 수 있도록 할 필요가 있다. 만약 WARN 로그까지 모두 슬랙으로 알림을 받는다면, 개발자는 실제로 중요한 ERROR 로그를 놓칠 수 있기 때문에 ERROR 로그만 슬랙으로 알림을 받도록 설정하는 것을 선호한다.

 

 

 

[ 적합한 로그 레벨의 중요성 ]

서비스를 운영하다 보면 다양한 레벨의 로그를 남기게 된다. 하지만 적당한 수준과 양으로 로그를 남기지 않으면 여러 문제가 발생할 수 있다.

먼저 무분별하게 INFO 로그를 남길 경우에는 로그를 적재하는 저장소 시스템에 지나치게 많은 로그가 쌓일 수 있다. 이로 인해 저장소 시스템에 장애가 생겨 로그가 유실되거나 혹은 지나치게 많은 로그로 원하는 로그를 찾을 때 소요되는 시간이 급증할 수 있다.

무분별하게 WARN 또는 ERROR 로그를 남기는 것 또한 문제가 될 수 있다. WARN이나 ERROR 로그는 적재되는 양이 많지 않기 때문에, INFO와는 다르게 로그의 신뢰도 저하 및 알림 피로(Alarm Fatigue)에 의한 문제가 생길 수 있다. WARN이나 ERROR는 시스템의 비이상적 상태를 남기는 수준이다. 따라서 과도한 WARN 및 ERROR 로그는 모니터링 시스템에서 운영자가 중요한 이상 징후를 식별하기 어렵게 만든다. 또한 알림의 신뢰도 역시 중요한 문제인데, 만약 우리가 남긴 WARN 또는 ERROR 로그가 사실은 문제가 없는 거짓 양성(false positive) 에러 로그였다면, 그리고 이러한 상황이 지속된다면, 우리는 로그의 신뢰성을 잃게 되어 아무도 로그를 보지 않을 것이다. 일종의 양치기 소년이 남기는 로그가 되는 것이다.

우리가 남기는 로그들은 한 번 로그 수준이 정해졌다고 해서 고정되면 안된다. 시스템을 운영하면서 에러를 빠르게 인지하지 못한 경우, INFO 레벨을 WARN 레벨으로 혹은 WARN 레벨을 ERROR 레벨로 격상시킬 필요가 있다. 또는 지나치게 높게 ERROR 레벨로 설정되어 로그의 신뢰도가 저하되거나 알림 피로도가 누적되는 상황이라면, 이를 낮출 필요도 있다. 결국은 서비스를 운영하면서 상황에 맞게 각 로그의 최적 수준을 찾아가는 것이 중요할 것이다.