caffeine-library / release-everything

'Release의 모든 것'을 읽는 스터디
3 stars 0 forks source link

[additional] 로깅을 어떻게 활용하고 계신가요? #24

Closed leejaeseung closed 6 months ago

leejaeseung commented 8 months ago

연관 챕터

22

조사 내용

책에서 인스턴스의 상태 점검을 위한 도구로 로깅이 소개되었습니다. 입사 당시에는 로깅을 그렇게까지 중요하게 생각하지 않고 개발했던 것 같은데, 꾸준히 운영을 하다보니 로깅의 중요성을 좀 깨닫게 되는 것 같네요. (TPS 측정이나 장애 시 트러블슈팅, 타 팀과의 대사를 맞추는 작업 등등.. 되게 많이 활용했던 것 같아요)

이번 기회에 어떻게 로그를 활용하고 있는지 서로 공유해보는 것도 좋을 것 같아 이슈를 남겨 봅니다 ㅎㅎ

등등.. 기억에 남는 로그는 요정도인 것 같은데 다른 팀들은 어떨지 궁금해지네요(팁 같은 거라도?!ㅋㅋ)

개인적으로 예전에 로그 데이터로 재처리를 하는 로직이 있다고 들었던 것 같아서 로그 파일을 어떻게 재처리 로직으로 태우는지 궁금하기도 합니다.! (직접 서버에 접속해서 로그 파일을 꺼내오는지? 아니면 원격으로 로그 파일을 긁어오는 기능을 개발한건지..?)

@caffeine-library/readers-release-everything

kth990303 commented 8 months ago

사내에선 인프라가 거의 aws 클라우드 클라우드 환경을 이용하고 있어서, 데이터센터 hostname 로깅 정보를 남기는 모습이 인상깊네요.

로그 활용

일단 저는 주로 팀에 문의가 들어왔을 때나 장애대응 시에 로그를 확인하고 있어요. 쿠폰팀 api timeout이 발생했으니 확인해달라는 요청, 고객이 쿠폰코드 발급이 안된다고 요청이 왔으니 확인해달라는 요청(보통은 고객님들께서 코드입력 오타인 경우가 대부분입니다.), 장애 발생 시 어디서 예외가 발생했는지 확인할 때 등. 다양한 상황에서 로그를 활용하고 있습니다.

트러블슈팅 상황 공유

장애 대응 시에 로그를 확인하는 사례 공유드릴 겸, 이야기 나누면 좋을 거 같은 상황 공유드립니다. 최근에 jenkins 배치 서버에서 로그 저장공간 용량 부족으로 인해 매일 새벽에 돌아야 하는 배치가 실패한 적이 있는데요. 메시지로 로그 공간이 부족하다고 뜨고 실패한 것으로 보이지만, 실제 용량이 충분한 EBS를 사용중이었어서 확신이 들지 않는 상황이었습니다. 그렇기 때문에 로그로 EBS 디스크 잔여 용량 추이 정보를 확인해보고 싶었는데 cloudwatch-agent 를 설정하지 않으면 불가능한 거 같더라고요.

EBS 볼륨의 현재 잔여 용량 확인 방법은 EC2에 직접 들어가서 https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-describing-volumes.html#ebs-view-free-disk-space 대로 명령어를 입력하면 되지만, 디스크 잔여량 추이 정보를 보긴 어려운 것 같았습니다. 클라우드와치에서 EBS volume write 양을 확인하는 수는 있지만, disk 잔여량 정보는 확인이 어렵더라고요.

결국 정확한 원인은 확인하지 못했고, 임시 대처방안으로 Pipeline 내 Job 실패 시 재시도 처리 및 OpsGenie 알림 전송(https://kth990303.tistory.com/474, 제 블로그 홍보 겸 달아봅니다 ㅋㅋ) 로 해두었는데요 😅 cloudwatch-agent 설정의 필요성을 느꼈고, 재빈님과 이야기 나눠보며 조언을 구해보고 싶기도 했습니다.