로그레벨 외의 Logger 분리 질문

dgyoon님 안녕하세요!답변이 늦었습니다. 죄송합니다. (_ _) 인프런 AI 인턴이 이미 잘 답변해준 것 같네요. ㅎㅎ그래도 저도 답변을 남겨보면, 로그를 내용에 따라, Logger 분리를 하는 방법 (Access.log, app.log, security.log, error.log 등등) 도 있는 것으로 알고 있는데요. 실무 API 서버경우에도 이렇게 로그레벨 이외에 Logger 분리를 하는 방법을 많이 사용하시는지 궁금합니다.-> 넵 실무에서도 로그 레벨 외에도 목적에 맞게 Logger를 분리하여 별도의 로그로 남기는 경우가 많이 있습니다. 다만, 개인적으로 법적으로 필요한 사항(ex. 개인정보보호법 관련 민감 기능, 데이터 접근에 대한 로그)이 아니라면 애플리케이션 전체에 해당하는 로그로 함께 수집하고, 법적으로 필요한 사항에 대한 로그를 따로 나누는게 전체 로그를 활용하기 용이한 것 같습니다. 함께 로그로 남아 있어야 수집 후 활용하기에도 용이하기 때문입니다.다만, access 로그에 요청 파라미터 등 로그의 용량이 너무 커서 관리가 어렵거나, 보관 기간을 달리해야한다면 애플리케이션 전체에 해당하는 로그로 퉁쳐서 보관하는건 적절하지 않고 이 경우라면 Logger를 나눠서 저장하는게 더 적절할 것 같습니다. 1번과 연관된 질문으로, 복잡한 실무 ELK 환경에서는 어플리케이션 로그의 경우, 한가지 로그에 몰아서 하는 방식을 많이 사용하는지, 각각 로거로 분리하고 elasticsearch index도 분리하는 방식을 많이 사용하는지 궁금합니다.-> 위에 답변드린 내용 마지막에 이야기드린 내용에 해당하는 것 같은데요, 목적이나 보관 기간이 분명하게 다르다면 index를 분리하는게 적절할 것 같습니다! 이 경우라면 실무에서도 나누는게 일반적입니다. 혹시 추가적으로 궁금한 내용 있으면 질문 남겨주세요!!감사합니다.

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

Layton AI님 안녕하세요!우선 강의 잘 들어주셔서 감사합니다. 😃 그럼 질문 주신 내용에 대해 답변드려볼게요! 개인적으로 trace나 debug 레벨과 같은 로그도 수집을 필수적으로 하는지 궁금합니다.보관 기간을 3~7일 정도로 짧게 해서 저장한다고 하면 어차피 금방 제거되는 로그를 수집하는 이유가 있을지 의문이 들어서요!-> 어떤 레벨의 로그도 필수적이지는 않습니다. 특히 운영 환경에서는 debug 로그나 trace 로그를 남기지 않는 경우도 많이 있어요. (개발 환경에서는 남김) 다만 두 로그 레벨은 목적에 맞게, 특정 데이터를 추적하는 용도라면 trace, 개발 과정에서 필요한 디버깅 용도라면 debug를 주로 사용하면 됩니다. 만약 콘텐츠 추적등을 이유로 trace, debug 레벨의 로그를 보관하기로 했다면, 질문주신대로 보관 기간을 짧게 유지하는 것도 좋은 방법입니다. 🙂그런데 이렇게 짧게 유지할거면 로그로서 기능을 못하는거 아닌가 하는게 질문의 요지겠죠? 짧게 유지되더라도 로그로서는 분명 도움이 될 때가 있습니다. 운영 환경에서 로그를 확인해야하는 경우 중 대부분은 최근에 발생한 데이터인 경우가 많습니다. 기간으로 따지면 대략 1주일 안쪽의 로그들을 자주 보게 되는 것 같아요. 혹은 실시간으로 데이터가 처리되고 있는 걸 로그로 보고 싶은 경우도 많이 있습니다. 이런 목적이라면 3~7일 정도로 짧게 저장하는 것도 도움이 되겠죠?그러나 모든 로그를 이렇게 짧게 보관하면 말씀하신 것처럼 로그로서의 가치가 떨어질 수 있습니다. 그래서 중요도, 필요한 보관 기간을 나눠서 로그 레벨별로 로그를 계층화하여 저장하는게 좋습니다. 강의 에서 이야기한 것처럼, 길게 보고 싶은 로그는 더 높은 레벨(info)로 저장하고 짧게 보고 싶은 로그들은 debug나 trace로 저장하라는 것입니다. debug 레벨 로그는 분석이 필요할 때만 그 때 그 때 심고 필요가 없어지면 지우는 게 맞을까요? 보통은 trace 레벨 로그를 더 많이 쓰는지도 궁금합니다. -> 이건 지정하기 나름입니다. 진짜 이번만 필요한거라면 이번에만 로그를 추가했다가 다시 로그를 지워줘도 괜찮고, 영구적으로 필요할 것 같다면 남겨놔도 괜찮습니다. trace 레벨의 로그보다는 주로 debug 레벨의 로그를 더 많이 사용하는 것 같습니다. 라이브러리 차원에서 찍히는 로그들 역시 debug 레벨인 경우가 많습니다. 인프런 AI 인턴이 이미 잘 답변해준 것 같아서, 추가적인 내용은 해당 답변 참고해보시면 도움이 될겁니다!혹시 또 궁금한 내용 있으면 질문 남겨주세요. 감사합니다.

recordException을 지정하지 않았을때 동작 방식 질문

soap님 오래 기다리셨습니다! 관련해서는 https://resilience4j.readme.io/docs/circuitbreaker#failure-rate-and-slow-call-rate-thresholds 에 아래와 같은 내용이 있습니다. Failure rate and slow call rate thresholdsThe state of the CircuitBreaker changes from CLOSED to OPEN when the failure rate is equal or greater than a configurable threshold. For example when more than 50% of the recorded calls have failed.By default all exceptions count as a failure. You can define a list of exceptions which should count as a failure. All other exceptions are then counted as a success, unless they are ignored. Exceptions can also be ignored so that they neither count as a failure nor success.The CircuitBreaker also changes from CLOSED to OPEN when the percentage of slow calls is equal or greater than a configurable threshold. For example when more than 50% of the recorded calls took longer than 5 seconds. This helps to reduce the load on an external system before it is actually unresponsive.The failure rate and slow call rate can only be calculated, if a minimum number of calls were recorded. For example, if the minimum number of required calls is 10, then at least 10 calls must be recorded, before the failure rate can be calculated. If only 9 calls have been evaluated the CircuitBreaker will not trip open even if all 9 calls have failed. 즉, Resilience4j에서 구현한 서킷 브레이커는 기본적으로 모든 예외(RuntimeException, Error 포함)를 실패로 간주합니다. 여기서 특정 예외를 recordException로 지정했을 때는 해당 예외의 하위 예외들로 실패로 간주되는 예외의 폭이 줄어드는 겁니다. 혹시 추가적으로 궁금한 내용 있으면 질문 남겨주세요!감사합니다.

Latency에 대한 질문이 있습니다!

김정우님 오래 기다리게해서 죄송합니다.관련해서 답변 드리겠습니다. 우선 Artillery는 FTTB(First Time To Byte)가 아닌 전체 패킷이 수신된 후를 기준으로 지연 시간을 계산합니다. 따라서, 스트리밍 서비스에서 오는 데이터 사이즈가 크다면 네트워크 대역폭에 따라 FTTB와 Atrillery가 계산한 지연 시간 사이에 꽤 큰 차이가 발생할 수 있습니다. 이 상황에서 어떤걸 목표로 삼을지는 어떤 서비스, 어떤 스트리밍 데이터인지, 어떤 성능을 튜닝하려고 하는지 등 개발자가 정해줘야할 것 같습니다. 만약 데이터 사이즈가 크다면 FTTB는 서버와 클라이언트 사이의 네트워크 지연 시간을 측정하는 데에만 참고로 활용하고, 실제 사용자가 체감하는 지연 시간은 패킷이 전체가 전달되는게 중요한 서비스라면 튜닝 대상을 패킷 전체가 전달되는 '전체응답을 다 수신한 뒤 지연율'을 타겟으로 튜닝을 해야할 것 같습니다. 다만 FTTB가 성능 튜닝의 목표가 되어야하는 서비스라면 Atrillery 말고 FTTB를 측정하고 모니터링할 수 있는 성능 테스트 툴을 사용해보시면 좋을 것 같습니다. 또한 전체 응답이 느려지더라도, 사용자가 FTTB만 충분히 빠르다면 서비스가 빠르게 동작하고 있다고 인지할 수 있는 UX를 만드는 것도 중요한 것 같습니다. 빨리 수신되어야하는 데이터와 사이즈가 큰 데이터를 구분하는 형태로요. 결과적으로 지연율을 어떤 기준으로 표기해줄지는 선택의 문제라고 생각됩니다!질문주신 내용에 대한 답변이 됐을까요?또 궁금한 내용 있으면 질문 남겨주세요.감사합니다.

recordException을 지정하지 않았을때 동작 방식 질문

soap님 안녕하세요!제가 현재 해외에 나와있어서 내일 복귀하는대로 답변 드리겠습니다.감사합니다.

Latency에 대한 질문이 있습니다!

김정우님 안녕하세요!제가 현재 해외에 나와있어서 내일 복귀하는대로 답변 드리겠습니다.감사합니다.

로그 레벨을 기준으로 알람 설정할 때, Kibana를 사용할 수 는 없나요?

denia park님 안녕하세요!질문 주셔서 감사합니다. 아래 AI 인턴이 잘 답변해줬는데, 현재 기준으로는 Kibana 무료버전에서도 자체적인 알람 기능을 제공합니다. Alerting 이라는 기능으로 사용할 수 있고, 관련된 내용은 아래 링크 참고해보시면 좋을 것 같습니다. https://www.elastic.co/guide/en/kibana/current/alerting-getting-started.html 강의 내에서 해당 기능을 활용하지 않고, Elasticsearch로 직접 쿼리를 날려서 확인하는걸 보여드린 이유는 Alert 기능으로 설정시 알람을 받아볼 대상을 지정하는 실습이 필요한데 이 부분까지는 강의에서 설명하려는 '로그 레벨'에 따른 알람 설정에서 벗어나는 내용인 것 같아서 간단히 포스트맨으로 aggregation이 가능하다는 것만 보여드리려고 현재처럼 구성했습니다. 🙂 강의 내용만 봤을 때는 Kibana는 해당 기능을 제공하지 않는 것처럼 오해하셨을 수도 있을 것 같습니다. 이 부분 혼동드려 죄송합니다. (_ _) 혹시 추가로 궁금한 내용 있으면 질문 남겨주세요.강의 잘 봐주셔서 감사합니다!

안녕하세요

wnsqud70님 안녕하세요~이 문제는 제가 직접 확인해봐야 할 것 같습니다. ㅠ혹시 괜찮으시다면, lleellee013@gmail.com 으로 메일 부탁드리겠습니다!

표준출력보다 Slf4J가 느릴 때

dlsrksrhk님 강의 내용에서 더 심화된 분석 글 감사합니다!AsyncAppender에 대한 내용도 언급할까 하다가 환경에 따라 차이가 나지 않을 수도 있어서 다루지 않았는데, 테스트 해주신 것처럼 표준출력이 오히려 빠른 경우 AsyncAppender로 변경했을 때 표준출력보다도 빨라질 수 있습니다.마지막에 이야기 해주신 것처럼, 성능 문제를 떠나서 로그 관리 차원에서 로깅 프레임워크 활용하는게 좋고, 실무 환경이라면 표준 출력이 경쟁적인 상태가 될 거라 로깅 프레임워크를 활용하는게 더 높은 성능을 보일겁니다. 😀남겨주신 내용은 제가 강의 노트란에도 추가해두겠습니다~감사합니다!!

강의 내용을 어느 정도로 파악하고 있는 것이 좋을까요?

형씌님 안녕하세요.우선 질문 주셔서 감사합니다. 프로그래밍을 처음 했을 때로 돌아가보면, 처음에는 하나씩 따라해보면서 문법을 익히고, 그 과정을 이해하면서 자연스레 문법들이 외워졌던 것 같습니다. 물론 처음에 잘 외워지지 않더라도 계속 반복해서 비슷한 코드를 작성하다보니 어느 순간 외워졌던 것 같아요. if 문은 조건식이 참일때 실행이 된다던지,for 문에는 초기식, 조건식, 증감식 순으로 넣어야 한다던지,변수에 대입은 = 로 하고, 실제 동일한지 비교는 ==로 한다던지 같은 것 처럼요. 제가 비록 형씌님이 얼마나 많은 프론트엔드 코드를 작성했는지 알지는 못하지만, 분명 이런 문법들 역시 반복해서 학습하고 작성하다보면 충분히 외워질겁니다. 다만 이걸 지금 꼭 외우고 넘어가야하는가 하면 저는 그렇지는 않은 것 같아요.백엔드 개발자라면 백엔드 개발과 관련된 부분에 좀 더 힘을 싣고 학습하는게 좋을 것 같습니다.프론트엔드 코드는 저도 아직 검색하여 작성하는 경우가 많습니다. 저도 자주 작성하지는 않거든요.물론 강의에서 사용한 코드 정도는 저도 대개는 외워서 작성하는 경우도 있긴 하지만, 이 외의 코드들은 상대적으로 IDE의 도움을 적게 받으면서 작성하는건 아직도 어렵습니다. 만약 프로그래밍 자체를 처음 배우는 사람이라면 외워서 작성할 수 있을 때까지 작성해보라고 권해드리겠지만, 지금 이미 백엔드 언어로 프로그래밍을 하고 계시기 때문에 그럴 필요는 없이 검색해서 작성할 수 있을 정도여도 괜찮을 것 같습니다. 길게 이야기 드렸는데, 혹시 또 궁금한 내용 있으면 질문 남겨주세요.감사합니다.