개발과 일상

개요난 꽤 오랫동안 "서비스 로그를 어떻게 남겨야 할까?"라는 고민을 해왔고, 이 고민은 다음의 블로그 글들로 이어져 왔다.스프링부트 서비스에 LOG 남기기 (with. Logback)스프링부트 AOP를 이용해 로깅 처리하기스프링부트에서 Multipart/form-data 요청의 MultipartFile 정보 로그 남기기Terraform으로 EKS 배포하기 11. Grafana Loki와 로그 모니터링 로그를 남길 때 가장 많이 고민한 건 다음과 같은 질문들이었다. API마다 어떤 로그를 남겨야 하는가?예외 발생 시 어떤 정보를 남겨야 대응하기 좋을까?known 에러는 어떻게 표기할까?서버 에러는 어떻게, 또 알람은 어떤 기준으로 발생시킬까?이번 서비스 개발을 계기로, 어느 정도 최종안을 정리할 수 있었..

개요사실 로그 파이프라인은 인프라 초기 설계 단계에서 함께 고민했어야 했지만, ECS 기반 인프라를 구성할 당시에는 방법을 몰라 한동안 손대지 못하고 있었다. 그 대신 임시 방편으로 로그를 데이터베이스에 저장하고, 단순히 스택 트레이스를 확인할 수 있게만 만들어둔 상태였다. 하지만 로그를 DB에 저장하는 방식은 여러모로 바람직하지 않다.첫째, 서비스 로직에 필요한 DB 커넥션 풀을 로그 기록 때문에 점유하게 된다.둘째, 불필요한 DB I/O가 발생해 비용 낭비로 이어진다.셋째, 로그는 개발자나 운영자를 위한 정보인데, 이를 위해 운영 데이터 저장소의 용량을 소모하게 된다.그리고 마지막으로, 검색과 필터링도 DB 쿼리로 해야 하기 때문에, 로그 시스템 고유의 장점인 빠른 탐색/집계 기능을 기대하기 어렵다...

내가 막 입사했을 때만해도 로그 관리 자체가 안되고 있었다. Cloud Watch를 뒤적거리던가, ArgoCD 대시보드에서 컨테이너에 접근해서 로그를 파악했다. .... 그래서 DevOps 관리자 분과 가장 먼저 협업한 것이 로그 파이프라인 구성이었다. 내가 한 일은 다음과 같다. 1. Application 단에서 발생한 로그를 어느 단위로 남길 것인지 판단하고 필요한 정보를 검토2. 검토된 정보들을 로그로 만들어 JSON 형태로 남김3. LogQL 쿼리로 Loki 데이터를 쿼리해서 Grafana에 대시보드를 추가 DevOps 관리자분은 따로 작업하셨어서 어떤 일을 했었는지 정확히 알기 어려웠는데, 이번 기회에 잘 알게 됐다. DevOps 관리자분이 한 일은 다음과 같다. 1. JSON 형태의 로그가 생..

작년 입사 후 얼마 지나지 않아서 로그 파이프라인을 구성했었다. 2023.05.28 - [개발/SPRING] - 스프링부트 서비스에 LOG 남기기 (with. Logback) 당시에는 요청에 대한 로그가 없어서 급하게 구축하게 됐는데, 지금 생각해보면 입사한지 한달도 되지 않은 개발자가 로그 파이프라인을 구성한다는 자체가 말이 좀 안되는 일이긴했다. 그래서 로그 파이프라인에 구멍이 조금씩 있었는데, 최근에 가장 큰 구멍을 알게되서 개선이 필요했다. 바로 Multipart/form-data 형식에서 MultipartFile에 대한 처리가 없어서, 어떤 파일이 업로드가 되었는지 알 수 없었다. 그런데, 현재 담당하고 있는 서비스가 파일 업로드를 지원하기 때문에 로그의 개선을 필요로 했다. 로그를 몇 번 개선..

문제의 발생 새로운 프로젝트를 시작하면서, 로그를 다시 붙여야할 일이 생겼다. 기존 프로젝트에 로그를 개발하면서 했던 파이프라인을 그대로 가져와서 붙여넣었는데, POST 요청에서 이상하게 동작하지 않았다. 원인을 분석하면서 생긴 일을 정리해보려고 한다. 우선 현재 시스템에서 로그를 어떻게 찍는지 간단히 정리해보고 가자. 1. Controller에서 API 요청을 받아서 서비스로직까지 처리한 후 return 2. 이 return 할 때 AOP AfterReturning을 통해 캐치 3. 이때 발생하는 return object와 요청 정보를 담고 있는 HttpServletRequest을 통해서 로그를 생성 이 과정 중 3번에서 문제가 발생했다. 사실 스프링부트에서 POST 요청의 RequestBody를 가져..

이전글 스프링부트에 로그 남기기의 개선 사항이다. 이렇게 로그를 남기려고 하니, 몇 가지 문제가 있었다. 1. 로그가 두 번 남는 문제 2. message에 똑같은 로그가 한번 더 출력되는 문제 3. 모든 API 마다 set을 해줘야함 4. 윗 글엔 작성하지 않았지만, 요청 객체를 남기는 방식의 문제 이번 글에서는 1, 2, 3번 내용만 다룰 거고, 4번은 다음 글에서 다루려고 한다. 로그가 두번 남는 이슈 이 문제는 slf4j와 logback 설정을 잘못 이해해서였다. 기존 logback-spring.xml을 열어보면 아래와 같이 설정되어 있었다. [ignore] [ignore] [ignore] [ignore] [ignore] [ignore] [ignore] 별도의 새로 구현한 로그매니저를 통해 관리하..

이직 후 맡은 첫 작업은 LOG 였다. 서비스 분석을 위해 코드를 처음 까봤을 때 굉장히 당황스러웠던 게 몇가지 있었는데, 그중 대표적인게 로그 부분이었다. 당황스럽게도, 남기고 있는 로그들은 전부 디버그 수준에서 남길만한 정보들만 남기고 있었다. if (oldUser != null) { log.info("이미 존재하는 사용자입니다. user : {} oldUser : {} ", user, oldUser); userResponseDTO.setCode(-1); userResponseDTO.setErrorMsg("이미 존재하는 사용자입니다."); return userResponseDTO; } 위와 같은 메시지들이 json 형태도 아닌 일반 cout 형태로 출력되고 있었다. 이런 로그들은 서비스를 운영하고 모..