Prometheus + Grafana 모니터링 구성 추가

[minibr]

관련 이슈

• close Prometheus + Grafana 모니터링 시스템 구축 #226

PR 설명

• Prometheus + Grafana 기반 HTTP 모니터링 시스템 구축
• EC2 리소스 절약을 위해 HTTP 메트릭만 수집 (JVM/시스템 메트릭 비활성화)

구현 내용

수집 메트릭

• HTTP Request Rate: 초당 요청 수 추이
• HTTP Error Rate: 4xx/5xx 에러율 (%)
• HTTP Response Time: 응답 시간 백분위수 (p50, p95, p99)
• Requests by Status Code: 상태 코드별 분포
• Top 10 Slowest Endpoints: 가장 느린 API 10개
• Top 10 Most Requested Endpoints: 가장 많이 호출되는 API 10개

리소스 설정

• Prometheus/Grafana 각 메모리 256MB 제한
• 메트릭 스크래핑 간격: 30초
• 데이터 보존 기간: 3일

Grafana 대시보드

• HTTP Request Rate: 초당 요청 수 추이
• HTTP Error Rate: 4xx/5xx 에러율 (%)
• HTTP Response Time: 응답 시간 백분위수
• Requests by Status Code: 상태 코드별 분포

배포 준비 완료 작업

• GitHub Secrets에 GRAFANA_ADMIN_PASSWORD 추가
• GitHub Secrets의 APPLICATION에 management 설정 추가
• EC2 보안그룹에서 3001 포트 오픈

접속 방법

1. PR 머지 → CD 자동 실행 → 배포 완료
2. 접속 URL:
   - Grafana: http://(EC2-IP):3001
3. Grafana 로그인: admin / 노션 참조
4. 좌측 메뉴 → Dashboards → Linkiving HTTP Overview 선택

[github-actions]

📊 코드 커버리지 리포트

Overall Project	93.95%	🍏

There is no coverage information present for the Files changed

[ckdals4600]

@minibr 모니터링 시스템 구축하시느라 고생 많으셨습니다! 적용된 Grafana 대시보드의 실제 예시 사진과 팀원들을 위한 간단한 접속/사용 방법을 PR 내용에 같이 첨부해 주시면 내용 파악에 훨씬 도움이 될 것 같습니다. 감사합니다!

[minibr]

@minibr 모니터링 시스템 구축하시느라 고생 많으셨습니다! 적용된 Grafana 대시보드의 실제 예시 사진과 팀원들을 위한 간단한 접속/사용 방법을 PR 내용에 같이 첨부해 주시면 내용 파악에 훨씬 도움이 될 것 같습니다. 감사합니다!

넵 확인했습니다.

[Goder-0]

이번 모니터링 구성은 애플리케이션/도커 설정만으로 끝나지 않고, 실제 접근 경로 기준으로는 Nginx 라우팅이나 EC2 Security Group 설정까지 함께 맞아야 할 것 같은데요. 혹시 /actuator/prometheus, 9090, 3001 관련해서 외부/내부 접근 정책을 어떻게 가져갈지도 같이 정리해두신 부분이 있을까요?

예를 들어 Prometheus/Grafana를 외부에 직접 노출할지, Nginx 뒤에서 제한할지, 특정 IP만 허용할지 같은 운영 전제가 있어야 실제 적용 시 혼선이 적을 것 같아서 질문드립니다.

[Goder-0]

현재 로직은 Prometheus/Grafana가 이미 실행 중이면 up -d prometheus grafana를 아예 건너뛰도록 되어 있는데요. 이번 PR처럼 prometheus.yml이나 Grafana dashboard/provisioning 파일이 변경된 경우에도, 기존 컨테이너가 떠 있으면 설정 변경이 실제 운영 환경에 반영되지 않을 가능성은 없을까요?

의도상 “최초 1회만 기동”을 생각하신 건지, 아니면 설정 파일 변경 시에도 재기동 또는 reload가 필요하다고 보신 건지 궁금합니다. 어떻게 생각하시나요?

[minibr]

말씀하신 대로 현재 로직은 컨테이너가 실행 중일 때 설정 변경이 반영되지 않는 문제가 있습니다. 의도는 "최초 1회만 기동"이었으나, 이는 설정 파일 변경 시 수동 재기동이 필요한 구조라 개선이 필요했습니다. docker compose up -d는 변경사항이 없으면 컨테이너를 그대로 유지하고, 설정이 바뀐 경우에만 재생성하므로, 조건 체크를 제거하고 항상 실행하도록 수정했습니다.

[minibr]

이번 모니터링 구성은 애플리케이션/도커 설정만으로 끝나지 않고, 실제 접근 경로 기준으로는 Nginx 라우팅이나 EC2 Security Group 설정까지 함께 맞아야 할 것 같은데요. 혹시 /actuator/prometheus, 9090, 3001 관련해서 외부/내부 접근 정책을 어떻게 가져갈지도 같이 정리해두신 부분이 있을까요?

예를 들어 Prometheus/Grafana를 외부에 직접 노출할지, Nginx 뒤에서 제한할지, 특정 IP만 허용할지 같은 운영 전제가 있어야 실제 적용 시 혼선이 적을 것 같아서 질문드립니다.

좋은 지적 감사합니다. 아래와 같이 접근 정책을 정리하고 적용했습니다.

/actuator/prometheus

• Prometheus는 도커 내부망(app-network)에서 blue:8080, green:8080으로 스크래핑하므로 외부 포트를 통하지 않습니다.
• 추가로 Nginx에서 /actuator/ 경로를 deny all 처리하여 외부 접근을 차단했습니다.

/9090 삭제

Grafana (3001)

• 팀원 전체가 원격으로 접근해야 하는 환경이라 IP 제한 대신 Grafana 자체 인증으로 관리합니다.
• GF_USERS_ALLOW_SIGN_UP=false 설정과 Secret으로 관리되는 관리자 비밀번호로 접근을 제한합니다.

[ckdals4600]

@minibr
로컬 테스트를 진행하려고 하는데 3001, 9090 접속이 되지 않습니다, 혹시 로컬에서의 정확한 접속 방법을 알려주실 수 있을까요?
그리고 이후 설정 공유를 위해 이번에 반영된 내용을 서버 application.yml 노션에도 함께 업데이트 부탁드립니다!