trace나 debug 레벨과 같은 로그도 수집을 필수적으로 하는... - 인프런

개발자에게 필요한 로그 관리

로그 고도화하기

trace나 debug 레벨과 같은 로그도 수집을 필수적으로 하는 편이 좋을까요?

작성

안녕하세요, 강사님. 우선 강의 잘 듣고 있습니다!

실무에서는 어떤 식으로 로그 관리가 진행되는지 궁금합니다.

개인적으로 trace나 debug 레벨과 같은 로그도 수집을 필수적으로 하는지 궁금합니다.
보관 기간을 3~7일 정도로 짧게 해서 저장한다고 하면 어차피 금방 제거되는 로그를 수집하는 이유가 있을지 의문이 들어서요!
debug 레벨 로그는 분석이 필요할 때만 그 때 그 때 심고 필요가 없어지면 지우는 게 맞을까요? 보통은 trace 레벨 로그를 더 많이 쓰는지도 궁금합니다.

감사합니다 :)

spring-boot elasticsearch logstash Kibana logback

답변 2

이준형(Foo)

지식공유자

Layton AI님 안녕하세요!

우선 강의 잘 들어주셔서 감사합니다. 😃

그럼 질문 주신 내용에 대해 답변드려볼게요!

개인적으로 trace나 debug 레벨과 같은 로그도 수집을 필수적으로 하는지 궁금합니다.
보관 기간을 3~7일 정도로 짧게 해서 저장한다고 하면 어차피 금방 제거되는 로그를 수집하는 이유가 있을지 의문이 들어서요!

-> 어떤 레벨의 로그도 필수적이지는 않습니다. 특히 운영 환경에서는 debug 로그나 trace 로그를 남기지 않는 경우도 많이 있어요. (개발 환경에서는 남김) 다만 두 로그 레벨은 목적에 맞게, 특정 데이터를 추적하는 용도라면 trace, 개발 과정에서 필요한 디버깅 용도라면 debug를 주로 사용하면 됩니다. 만약 콘텐츠 추적등을 이유로 trace, debug 레벨의 로그를 보관하기로 했다면, 질문주신대로 보관 기간을 짧게 유지하는 것도 좋은 방법입니다. 🙂

그런데 이렇게 짧게 유지할거면 로그로서 기능을 못하는거 아닌가 하는게 질문의 요지겠죠? 짧게 유지되더라도 로그로서는 분명 도움이 될 때가 있습니다. 운영 환경에서 로그를 확인해야하는 경우 중 대부분은 최근에 발생한 데이터인 경우가 많습니다. 기간으로 따지면 대략 1주일 안쪽의 로그들을 자주 보게 되는 것 같아요. 혹은 실시간으로 데이터가 처리되고 있는 걸 로그로 보고 싶은 경우도 많이 있습니다. 이런 목적이라면 3~7일 정도로 짧게 저장하는 것도 도움이 되겠죠?

그러나 모든 로그를 이렇게 짧게 보관하면 말씀하신 것처럼 로그로서의 가치가 떨어질 수 있습니다. 그래서 중요도, 필요한 보관 기간을 나눠서 로그 레벨별로 로그를 계층화하여 저장하는게 좋습니다. 강의 에서 이야기한 것처럼, 길게 보고 싶은 로그는 더 높은 레벨(info)로 저장하고 짧게 보고 싶은 로그들은 debug나 trace로 저장하라는 것입니다.

debug 레벨 로그는 분석이 필요할 때만 그 때 그 때 심고 필요가 없어지면 지우는 게 맞을까요? 보통은 trace 레벨 로그를 더 많이 쓰는지도 궁금합니다.

-> 이건 지정하기 나름입니다. 진짜 이번만 필요한거라면 이번에만 로그를 추가했다가 다시 로그를 지워줘도 괜찮고, 영구적으로 필요할 것 같다면 남겨놔도 괜찮습니다. trace 레벨의 로그보다는 주로 debug 레벨의 로그를 더 많이 사용하는 것 같습니다. 라이브러리 차원에서 찍히는 로그들 역시 debug 레벨인 경우가 많습니다.

인프런 AI 인턴이 이미 잘 답변해준 것 같아서, 추가적인 내용은 해당 답변 참고해보시면 도움이 될겁니다!

혹시 또 궁금한 내용 있으면 질문 남겨주세요.

감사합니다.

인프런 AI 인턴

안녕하세요, 인프런 AI 인턴입니다. Layton AI님.

로그 관리는 소프트웨어 개발에서 매우 중요한 부분이며, 실무에서는 상황에 따라 다양한 로그 레벨을 사용하여 시스템 상태와 문제를 진단합니다. 아래에 실무에서의 로그 관리에 대한 몇 가지 주요 포인트를 설명드리겠습니다.

1. Trace와 Debug 로그 수집

필수적인 수집 여부:
- Trace나 Debug 레벨의 로그는 매우 상세하며, 주로 개발 및 테스트 환경에서 사용됩니다. 이러한 로그들은 운영 환경에서는 너무 많은 양의 데이터를 생성하여 시스템 성능에 영향을 줄 수 있습니다.
- 실무에서는 일반적으로 Debug 및 Trace 로그를 모든 로그에 대해 항상 수집하지는 않습니다. 대신, 특정 이슈가 발생했을 때 분석 목적으로 일시적으로 활성화하는 경우가 많습니다.
보관 기간:
- 보관 기간을 짧게 설정하여 디스크 용량을 관리할 수 있습니다. 중요한 점은 필요한 정보가 빠르게 제거되어버리기 때문에, 중요한 이슈가 발생했을 경우 미리 로그를 백업해두는 것이 좋습니다.
- 이러한 로그들은 문제 해결 후에도 분석 자료로 사용할 수 있으므로 기간 내 확보된 로그는 신속하게 분석하여 필요시 아카이브를 만들어 보관하기도 합니다.

2. Debug 로그 관리

분석 필요 시:
- Debug 레벨 로그는 예측하지 못한 문제를 분석할 때 매우 유용합니다. 필요시에만 활성화하여 정보를 수집한 뒤, 문제가 해결되면 비활성화하여 성능을 유지하는 것이 일반적입니다.
- 보통 운영 환경에서는 Debug 로그를 활성화하지 않는 것이 일반적입니다. 필요한 경우, 예외적인 상황에서만 짧은 기간 동안 활성화하는 것이 권장됩니다.
Trace 로그:
- Trace 로그는 일반적으로 가장 상세한 수준이며, 일반적인 운영 기능에서 사용되기에는 부담이 될 수 있습니다. 보통은 Debug 로그보다 더 많은 데이터를 생성합니다.
- 실무에서는 성능 이슈, 복잡한 문제 해결이 필요한 경우를 제외하고 Trace 로그는 사용되지 않는 경우가 많습니다.

인프런 커뮤니티 질문&답변

trace나 debug 레벨과 같은 로그도 수집을 필수적으로 하는 편이 좋을까요?

1. Trace와 Debug 로그 수집

2. Debug 로그 관리

관련 질문 및 추가 자료