개발과 일상

내가 막 입사했을 때만해도 로그 관리 자체가 안되고 있었다. 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 형태로 출력되고 있었다. 이런 로그들은 서비스를 운영하고 모..