로깅 전략 생각

[woo-chang]

애플리케이션에서 발생하는 상황들에 대해 알기 위해서는 적절한 로깅 전략이 필요합니다. 로깅을 통해서 요청과 응답 정보를 확인할 수 있고, 발생하는 예외에 대한 정보도 얻을 수 있습니다.

이 정보를 통해 애플리케이션 개발 단계에서는 디버깅을 할 수 있고, 운영 단계에서는 애플리케이션에 대한 데이터를 수집할 수 있고 커스텀 서비스도 제공할 수 있습니다. 또한 발생하는 에러에 대한 대처도 가능합니다.

이를 위해 저희 팀도 로깅 전략에 대해 고민해보고 구성해보고자 합니다. 고민해야 할 부분에 대해 아래에 예시로 작성해 보았습니다. 아래 예시 외에도 생각할 부분이 많으니 많은 의견 부탁드립니다 :)

고민이 필요한 부분

• 로깅을 위해 어떤 기술을 사용하면 좋을지
• 어떤 것들을 로깅으로 남길 것인지
  • ex) 요청, 응답 정보에서는 어떤 데이터를 남겨야할까, 예외 상황에서는 어떤 데이터를 남겨야할까
• 로깅 메세지 형식은 어떻게 하면 좋을지
• 로깅 데이터는 어떻게 보관하면 좋을지
  • ex) 날짜를 기준으로 보관, 로그 레벨에 따라 보관
• 저장해야하는 로그 레벨은 어떻게 지정하면 좋을지
• 로그 데이터 백업은 어떻게 진행하면 좋을지

참고

• 로그 관리 모범 사례
• 효율적으로 로그 모니터링 하기

[jeomxon]

로깅을 위해 어떤 기술을 사용하면 좋을지

log4j, logback의 단점을 보완한 최신 기술인 log4j2를 채택하였습니다.

어떤 것들을 로깅으로 남길 것인지

최대한 많은 정보를 남기자!
현재는 서비스의 규모가 작기 때문에 최대한 많은 정보를 보여주고,
서비스의 규모가 커지면 차츰 필요한 최소의 정보만 가져갈 수 있도록 변경하기로 하였습니다.

로깅 데이터는 어떻게 보관하면 좋을지

기본적으로 날짜를 기준으로 보관하고, ERROR레벨만 분리하여 따로 보관하기로 결정했습니다.
날짜를 기준으로 보관할 때는 로그레벨에 구분없이 많은 양의 정보를 한번에 보기 편하고,
ERROR를 통해 치명적인 에러만 분리하여 볼 수 있다는 장점도 있어서 해당 방식을 채택했습니다.

저장해야하는 로그 레벨은 어떻게 지정하면 좋을지

• 로컬 : DEBUG
• 개발 : DEBUG
• 운영 : INFO

로그 데이터 백업은 어떻게 진행하면 좋을지

• 개발 : 하루 기준으로 롤링
• 운영 : 6시간 기준으로 롤링