로깅 앤 디버깅

 

 

서비스 장애

 

 

 

 

 

 

모니터링

 

 

모니터링 하는 이유 ?

 

지속적으로 봄으로써 우리 서비스에 장애 판별 여부를 파악 및 장애 방지

 

 

-> 응답이 늦다 ?

 

cpu 사용 급등 , 메모리 부족 등등..

 

 

 

사용자의 불편함을 초래하는 이슈들이 발생할 수 있는 것을 "미리" 체크

 

 

 

cloud watch 예시

 

cpu, 메모리, 네트워크, 등등을 확인

 

 

 

IF) 장애를 초래한 원인을 제대로 분석하지 않는다면 ?

 

단순한 서버 티어 올리기 ?

 

 

 

단순한 해결책이다. 

 

올리면 모든 게 해결되지만 한정된 자원으로 최고의 효율을 내야 하기에

 

 

 

 

 

즉 모니터링을 하므로써 서비스 장애 방지 및 비용을 최적화

 

 

 

 

 

그러면 누가 모니터링을 하고 있어야 하나 ?

 

 

 

 

 

 

응답의 기준으로 장애를 잡는다면 ?

 

 

 

1 .5초 이상의 응답이 계속 걸린다 -> (하나가 느려지면 연쇄적으로 응답이 다 느려짐)

 

2. 기준에 따라 알림을 적절한 대상에게 고지 -> email, slack 등 정의

 

 

 

 

다시

 

 

 

 

비용 최적화 & 유저 경험

 

 

 

 

 

 

 

어느 시점에 로그를 남겨야 좋을 것인가 ?

 

 

 

추천하는 곳은 예외처리 및 중요한 영역, 복잡한 로직 등을 정해서 남기기

 

 

 

에러를 넘기는 상황에서 의미있게 로그를 남기고, 넘겨주는 방식

 

 

 

지속적으로 쌓이는 로그는 어떻게 관리 ? 무의미한 상황이 된다면 삭제할 경우도 생각

 

 

 

로깅 레벨 

 

 

 

 

 

 1. debug

운영이 아닌 개발 단계에서 사용

 

 

 

 

2. INFO

 

 

동작의 흐름을 파악하는 과정

 

외부 서비스를 호출하는 경우에 사용한다면, 외부 서비스의 성공 여부를 파악할 수 있다

 

 

 

 

3. WARN

 

 

긴급하지 않지만 잠재적으로 ERROR 레벨로 변화할 수 있는 문제들

 

 

 

4. ERROR

 

 

즉각적인 대응이 필요한 레벨, WARN이 반복된다면 ERROR 레벨로 

 

 

5.  FATAL

 

 

 

 

로깅 레벨은 서비스 마다 달라질 수 있으며, count해서 반복의 여부를 잘 파악 해야함

 

 

 

 

 

 

모든 로그는 좋지 않다.

 

시간을 아끼려고 로그를 남기는데, 자세하지 않거나 로그를 찾는데 더 오래 걸린다면 fail

 

문제 발생 시 자세한 로그를 통해 어디서 문제가 나왔는지 파악하기 쉬워짐