[DevOps] 모니터링 환경 구축 Prometeus, Grafana, Loki, Promtail - Modie

이번엔 각 데브서버와 프로덕션 환경의 모니터링 세팅을 어떻게 하였는지 정리해보겠습니다.

모니터링은 왜 해야할까?

운영 중인 서버와 애플리케이션은 항상 다양한 위험에 노출되어 있습니다.
서버 리소스(CPU, Memory, Disk 사용량)나 애플리케이션 상태를 실시간으로 관찰하지 않으면
문제가 발생했을 때 즉각적으로 대응할 수 없습니다.

-> 따라서 모니터링은 문제 예방과 빠른 대응을 위한 필수 요소입니다.

모니터링은 뭘로 하지?

제목에도 써있다싶이 Prometheus, Grafana, Loki, Promtail을 사용하여 모니터링 서버를 구축하였습니다.

각각의 역할을 간단히 정의하면

Prometheus - 메트릭 데이터를 수집하는 시스템

Grafana - 수집된 데이터를 시각화하고 대시보드를 제공하는 시각화 도구

Loki - 로그 데이터를 저장하는 로그 수집 및 저장 시스템

Promtail - 서버의 로그 파일을 수집하여 Loki로 전송하는 로그 수집 에이전트

라 볼 수 있습니다.

도구는 이 정도를 선택했고 이 모니터링 도구들이 현업에도 보편적으로 쓰는 도구라 도입했습니다.

모니터링은 어떻게 하지?

모니터링 서버는 서비스 서버와 같은 VPC에 배치하고 Private IP로 통신하게 구성하는 것이 좋습니다.

그 이유는

• 지연을 최소화할 수 있고.
• VPC 내부 통신이기 때문에 보안 그룹 설정으로 쉽게 접근 제어할 수 있다.
• 별도 인터넷 게이트웨이 없이 Private IP 통신으로 트래픽 비용을 절약할 수 있다.
• 외부망을 통하지 않으니 보안 위험도를 줄일 수 있다.

요약하면 빠르고 안전하게 모니터링 데이터를 수집하고 전송할 수 있기 때문에
모니터링 서버는 서비스 서버와 같은 VPC에 두는 것이 가장 이상적입니다.

로그 모니터링 구조

애플리케이션 로그는 Promtail → Loki → Grafana 아키텍처로 수집 및 시각화하였습니다.

• Promtail이 Docker 컨테이너 내 로그 파일을 수집하여 Loki로 전송하고,
• Loki는 수집된 로그를 저장 및 인덱싱하며,
• Grafana를 통해 로그를 실시간 검색 및 대시보드화할 수 있도록 구성하였습니다.

DEV 시스템 아키텍처(모니터링 구조 추가버전)

DEV서버 모니터링 전략

DEV 서버에서는 개발자가 최대한 빠르게 서버 상태를 모니터링하고 문제를 감지할 수 있도록
간편하고 직관적인 관측 환경을 제공하는 것을 목표로 설계하였습니다.

이를 위해 인스턴스를 퍼블릭 서브넷에 배치하여 퍼블릭 IP로 직접 접근할 수 있는 방식을 사용하였습니다.
복잡한 Bastion 접근 없이 바로 모니터링 서버에 접근할 수 있도록 함으로써
개발/디버깅 효율을 높였습니다.

Prometheus + Grafana 조합을 통해 수집하고 관찰한 데이터 항목은 다음과 같습니다:

• 서버 다운 여부: 인스턴스나 애플리케이션이 비정상 상태가 되는 경우 즉시 감지
• 특정 API 응답 지연: 응답 시간이 비정상적으로 늘어나는 요청을 조기에 포착
• 트래픽 집중 여부: 특정 URI나 엔드포인트로 비정상적으로 트래픽이 몰리는지 모니터링

Prometheus + Grafana 모니터링 화면

이러한 항목은 개발 환경(DEV) 특성상,
빠른 테스트와 디버깅, 그리고 배포 후 즉각적인 문제 탐지를 가능하게 하여
개발자의 생산성과 대응 속도를 높이는 데 중점을 두고 선정하였습니다.

DEV 서버 로그 관리 전략

로그 수집 및 시각화 측면에서도
문제 발생 시 빠른 원인 파악과 디버깅 편의성을 최우선으로 고려하여 설계하였습니다.

구체적으로는 수집된 로그를 로그 레벨별로 분리하여 관리하였고

ERROR	예외 및 치명적 오류 상황	장애 상황 빠른 인지 및 조치
WARN	주의가 필요한 경고 상황	잠재적 문제 사전 감지
INFO	일반적인 요청 흐름 및 정상 처리 기록	운영 흐름 파악 및 추적

수집된 로그는 Grafana를 통해 에러 로그, 경고 로그, 정상 로그로 나누어 대시보드에 표시하였으며
각 로그 항목에는 다음과 같은 메타 정보가 함께 기록되도록 설정하였습니다:

• 타임스탬프 (로그 발생 시각)
• 스레드명
• 요청 고유 ID (Request ID, MDC 기반)
• 로그 발생 클래스 및 라인 번호
• 상세 메시지

수집된 로그는 Grafana 대시보드를 통해
에러 로그, 경고 로그, 정상 로그로 각각 구분하여 시각화하였습니다.

로그 모니터링 화면

또한 각 로그 항목에는 다음과 같은 구조화된 메타 정보를 포함하도록 설정하였습니다.

• 타임스탬프 (로그 발생 시각)
• 실행 스레드명
• 요청 고유 ID (Request ID, MDC 기반)
• 로그 발생 클래스명 및 코드 라인 번호
• 상세 메시지 내용

이러한 구조화된 로그 관리를 통해

• 특정 시간대에 발생한 에러를 빠르게 추적하고
• 특정 요청에 대한 전체 흐름을 쉽게 분석하며
• 성능 이슈나 장애를 조기에 감지할 수 있도록 하였습니다.

PROD 서버 모니터링 전략

PROD 시스템 아키텍처(모니터링 구조 추가버전)

PROD 서버에서는 서비스 안정성과 장애 대응을 최우선으로 고려하여 모니터링 시스템을 설계하였습니다.

DEV서버와 다른 점은 모니터링 서버가 Private subnet에 위치해 있고 관리자는 Bastion jump를 통해 모니터링 서버에 접근하도록 하였습니다.

(Bastion Jump는 퍼블릭 서브넷에 위치하여, 외부에서 Private Subnet 내부 서버로 안전하게 접근하기 위한 중계 서버 역할을 합니다.)

PROD서버 역시 Prometheus + Grafana 조합을 통해 수집하였고 관찰한 데이터 항목은 다음과 같습니다:

DEV 서버에서 모니터링하던 기본 데이터 이외에도,

ASG를 사용하기 때문에 현재 몇 개의 인스턴스가 활성화되어 있는지를 추가로 확인할 수 있도록 구성하였습니다.

또한 JVM(Micrometer) 템플릿을 통해 다음과 같은 애플리케이션 레벨 지표들을 모니터링하였습니다.

추가로 수집한 주요 지표는 다음과 같습니다.

• JVM 메모리 사용량
  • Heap, Non-Heap 메모리 사용량을 실시간으로 모니터링하여 메모리 누수 가능성 조기 감지
• Garbage Collection(GC) 활동량
  • GC 발생 횟수 및 소요 시간을 수집하여 불필요한 GC로 인한 응답 지연 여부 확인
• JVM 스레드 수
  • 애플리케이션 내부 스레드 수를 추적하여 스레드 누수나 비정상 증가 여부 감지
• HTTP 요청 수 및 처리 시간
  • 애플리케이션 엔드포인트 별 요청 수와 평균 처리 시간 분석
• DB 커넥션 풀 상태(HikariCP)
  • 현재 활성 커넥션 수, 대기 커넥션 수 등을 모니터링하여 데이터베이스 연결 상태 점검

이를 통해 운영 서버의 전반적인 상태를 실시간으로 관찰하고,
장애 발생 가능성을 사전에 인지하여 빠르게 대응할 수 있도록 시스템을 구축하였습니다.

요약

DEV 서버는 빠른 디버깅과 개발 생산성을 위해,
PROD 서버는 안정성과 장애 대응을 위해 모니터링 시스템을 구축하였습니다.
Prometheus + Grafana 조합과 Promtail + Loki 아키텍처를 활용하여,
지표 모니터링과 로그 분석을 동시에 수행할 수 있는 통합 관측 환경을 구성하였습니다.

마무리

모니터링 도구를 세팅하고 서비스 출시 이후 직접 모니터링을 진행해 보니 매우 신기한 경험이었습니다.
"우리 서비스에도 이 정도의 트래픽이 발생하는구나"라는 사실을 수치 데이터로 직접 확인할 수 있었습니다.

또한 이러한 데이터를 기반으로,
개발자로서 어떤 대응을 준비해야 할지
어떤 부분에 가치를 추가할 수 있을지에 대해 더 깊이 고민하게 되었습니다.

모니터링은 단순히 수치를 보는 것이 아니라
서비스의 현재 상태를 이해하고 더 나은 방향으로 개선하기 위한 출발점임을 이번 경험을 통해 직접 느낄 수 있었습니다.

감사합니다.