푸으름

✏️ 들어가며Spring Boot로 개발하면서 log.info()는 매일 쓰지만, 그 한 줄이 어떤 과정을 거쳐 콘솔이나 파일에 찍히는지는 잘 몰랐다. 로그 체계를 개선하는 작업을 하면서 logback-spring.xml, Appender, Encoder, MDC 같은 개념을 계속 만났고, 한 번 제대로 정리할 필요를 느꼈다. 한 줄로 요약하면 이렇다. SLF4J는 개발자가 사용하는 로깅 인터페이스이고, Logback은 그 로그를 어떤 레벨·형식으로 어디에 출력할지 담당하는 구현체다. 즉 개발할 때는 log.info()처럼 SLF4J API를 사용하고, 그 로그를 콘솔이나 파일에 어떤 형식으로 남길지는 Logback이 처리한다. ✏️ 1. 전체 구조Spring Boot에서 로그는 대략 이렇게 흘러간다...

✏️ 들어가며운영 중인 서버에서 에러 알림이 왔다. Grafana에서 해당 요청의 로그를 찾아봤는데, 정작 원인이 담긴 스택트레이스가 보이지 않았다. 로그는 분명 수집되고 있었는데 "로그를 보고도 원인을 찾을 수 없는" 상황이었다. 이 글은 그 문제를 계기로 우리 서비스(Spring Boot 3.0 기반 학식 정보 서비스)의 로그 수집 체계를 처음부터 다시 점검하고 개선한 과정을 정리한 것이다. 사실 나는 로그 쪽을 잘 몰랐다. 그래서 개념부터 정리하고, 현재 구조를 분석하고, 문제를 하나씩 고쳐 나간 순서 그대로 적어 보려고 한다. ✏️ 1. 로그를 다루기 전에 알아야 할 개념1-1. 로그 레벨: "예외가 났다고 모두 에러는 아니다"로그 레벨을 정하는 기준은 "누구 잘못이냐"다.구분원인로그 레벨알림스택..

✏️ 문제 제기https://pooreumjung.tistory.com/587 [EAT-SSU / 잇슈] - Grafana Cloud + Alloy로 모니터링 구축✏️ 목차배경 및 목표Prometheus + Grafana 직접 구축을 포기한 이유최종 아키텍처구축 단계1단계 - Actuator 보안 강화2단계 - Management 포트 분리3단계 - Docker 포트 Publish4단계 - Grafana Alloy EC2 설치5단계 -pooreumjung.tistory.comEAT-SSU 서버는 이미 Grafana Cloud + Prometheus 조합으로 메트릭을 수집하고 있었다. Spring Boot Actuator가 /actuator/prometheus를 열어주고, dev/prod 각 EC2에서 ..

✏️ 배경발생 상황: 새 마이그레이션 파일이 있는 배포에서 리허설용 MySQL 컨테이너를 새로 띄우고, 준비됐는지 폴링 확인한 뒤 운영 DB 덤프를 복원하는 단계.원인: 준비 확인이 소켓 방식(mysql -uroot -e "SELECT 1")인데, mysql:8.0 컨테이너가 뜰 때 초기화용 임시 서버가 잠깐 떴다 꺼지고 그다음 진짜 서버가 뜸. 폴링이 임시 서버가 살아있는 타이밍에 걸리면 "준비 완료"로 착각하고 바로 복원을 시도 → 그 사이 임시 서버는 꺼져서 ERROR 2002로 실패.해결 방법: 준비 확인을 TCP 방식으로 변경.간결하고 명확한 RCA였다. 참고로 이 readiness 체크는 원래 mysqladmin ping을 쓰다가, 실제 인증까지는 보장하지 않는다는 걸 알고 한 번 mysql ..