푸으름

✏️ 문제 제기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 ..

✏️ 배경서버에서 5xx 에러가 나면 ServerErrorAlertService가 Discord webhook으로 알림을 쏘도록 이미 되어 있었다. 에러 시간, 요청 엔드포인트, 상태 코드, 클라이언트 정보, 에러 메시지, 스택트레이스(1,000자 제한)까지 알림 자체는 꽤 충실했다. 문제는 그 다음이었다. 알림을 보고 "아, 이거 원인이 뭐지"를 확인하려면 Grafana(Loki)에 들어가서 시간대랑 엔드포인트만 갖고 로그를 눈으로 훑어야 했다. 트래픽이 몰리는 시간대인 경우 같은 엔드포인트로 수십 건이 찍힐 수 있기 때문에, 알림에 찍힌 그 요청 하나를 정확히 짚어내는 게 사실상 불가능했다. 인프라를 다시 들여다보니 필요한 재료는 이미 다 있었다. 로깅 쪽 (logback-spring.xml) - p..

✏️ 들어가며Spring에서 캐시를 쓸 때 @Cacheable, @CacheEvict 정도는 금방 외워진다. "조회할 때 캐시부터 확인한다", "변경되면 캐시를 지운다"까지는 한 줄로 설명할 수 있다. 문제는 그다음이다. @Cacheable을 붙이면 대체 어디에 저장되는지, Redis인지 로컬 메모리인지, CacheManager는 무슨 역할을 하는지까지 가면 설명이 흐릿해진다. @Cacheable / @CacheEvict / @CachePut 세 어노테이션의 동작부터 시작해서, Spring Cache 추상화가 CacheManager를 거쳐 실제로 Redis나 Caffeine 같은 저장소에 어떻게 연결되는지, 그리고 이 어노테이션들이 내부적으로 AOP Proxy로 동작한다는 것까지 이어서 정리했다. ✏️..