로그 설정을 해보자-(1)

Alex·2024년 12월 25일
0

Plaything

목록 보기
59/118

인프런 -개발자에게 필요한 로그 관리 강의를 참고해서 로그 설정을 할 계획이다.

어떤 것을 로그로 남겨야 할까?

1) 트러블 슈팅에 도움이 될 것 같은 정보
2) 법적으로 필요한 경우

Sl4j를 사용해서 로그를 입력

만약 로그인이 안 된다면??

이렇게 로그인 API 사용이 됐다는 로그만 남기는 거랑
위처럼 어떤 로그인 과정에 사용된 정보들을 로그로 남기는거랑 트러블슈팅 측면에서 효율성의 정도가 다름.

CS 적인 관점에서 어떤 데이터가 필요한지 확인해야 함.
그렇다고 로그를 모든 API마다 남기는 것은 좋지 않음 -->로그 사이즈가 너무 커짐 (불필요한 로그를 제외해라)

중요한 것들

-요청, 응답에 대한 로그
-오류, 및 예외 로그
-사용자 활동 로그(보안 감사 추적-->주로 법적)
-시스템 상태 로그 --> 별도로 모니터링하는 시스템을 사용
-쿼리 전체를 남기는 것은 비효율적
-보안 로그 (로그인/로그아웃)
-디버깅 로그 -->주로 로컬 개발 환경(or 개발 서버에서)

예외와 로그

Checked exception과 UnChecked exception의 차이는?

예외는 모두 런타임 시점에 발생(컴파일은 문법적 에러를 말하는것)

Error: OOM, StackOverFlow(재귀함수에서 주로 발생)

그럼 어떤 예외를 사용해야 할까?

UnCheckException을 쓰는 게 좋다.

CheckedException을 쓰면 계속 throws를 해주고, try catch을 해줘야 한다.
사용자에게 응답을 전달하려면 계속 throws를 해줘야 함.
그래야 전역 예외처리 Handler가 처리 가능(언체크를 하면 굳이 이렇게 안 해도 됨)

CheckedException도 사용할만한 곳이 있긴함(다만, 사용자가 입력값을 잘못 입력한 사례 같은 경우는 UnCheckedException로 해도 충분함)

좀더 뾰족하게 로깅을 남기려면 이용자가 입력한 값을 로그에 남기도록 할 수 있다

로그 레벨이란?

이런식으로 설정을 할 수 있다.

모든걸 info로 찍는 건 좋지 않다. 오류는 아니면서 시스템의 중요한 기능 실행, 비즈니스 로직에 대해서

FATAL은 보통 시스템에서 자체적으로 찍히는 경우가 많다-->바로 개입해야 함

DTO 내부에 필드가 많아진다면, 하나씩 찍지 말고 DTO를 통째로 찍자. 다만, Trace가 너무 커질 수 있어서 문제 (참고로 toString해줘야 함)

info로는 생성된 shortedUrl이 무엇인지에 대한 정보(엔티티 생성, 엔티티 변화 -->이정도만 해라)

shrotenUrlKey 생성 부분에서 계속 문제가 생긴다면 이건 debug로 남겨볼 수 있다.

DB로 날라가는 쿼리들도 Trace나 Debug로 설정해둘 수 있음(info로 x)

warning 레벨은 단축 url을 찾지 못했다는 예외 던져질 때(이게 자주 발생한다?) -->waring으로 설정할 수 있음

error 레벨은 모든 exception이 아니다. (사용자 입력값과 관련된 걸 error x -->개발자 개입이 필요한 부분이 아님)

만약, 시스템과 시스템 사이의 호출이라서 NotFoundShortenUrlException이 발생하면 안된다? 그러면 Error(한번이라도 발생하면 크리티컬한 문제가 된다)

개발자가 직접 개입해야 하는지가 중요한 포인트

error 로그로 남길수도 있긴 하지만, 당장 개입이 필요한거라면 그냥 알림을 보낼 수도 있음

profile
답을 찾기 위해서 노력하는 사람

0개의 댓글