Prometheus와 Grafana를 이용한 통합 모니터링 시스템 구축

1. 모니터링 시스템 구축의 필요성

서비스가 마이크로서비스로 전환되면서 서버의 수가 늘어나고, 장애 발생 시 원인을 파악하는 것이 매우 어려워졌습니다. 기존에는 "서버가 느려요"라는 제보를 받으면 엔지니어가 각 서버에 SSH로 접속하여 top 명령어를 쳐봐야 했습니다. 이러한 수동적인 대응 방식에서 벗어나 사전에 징후를 감지하고, 데이터를 기반으로 의사결정을 하기 위해 Prometheus와 Grafana를 도입했습니다.

2. 아키텍처 설계

모니터링 시스템은 크게 수집(Exporter) - 저장(Prometheus) - 시각화(Grafana) - 알림(Alertmanager)의 4단계로 구성됩니다.

• Exporter: 각 서버 및 애플리케이션에서 메트릭을 노출 (Node Exporter, Spring Actuator 등)
• Prometheus: 주기적으로 Exporter에 접속하여 메트릭을 수집(Pull 방식)하고 시계열 DB에 저장
• Grafana: 저장된 데이터를 쿼리하여 대시보드로 시각화
• Alertmanager: 특정 임계치를 넘으면 Slack, PagerDuty 등으로 알림 발송

3. 설치 및 구성 (Docker Compose 활용)

관리가 용이하도록 Docker Compose를 사용하여 모니터링 스택을 한 번에 배포했습니다.

3.1 docker-compose.yml 작성

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:v2.45.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:10.0.0
    volumes:
      - grafana_data:/var/lib/grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=secret

  node_exporter:
    image: prom/node-exporter:v1.6.0
    ports:
      - "9100:9100"

volumes:
  prometheus_data:
  grafana_data:

3.2 Prometheus 설정 (prometheus.yml)

수집할 대상을 정의합니다. 여기서는 자기 자신(Prometheus)과 Node Exporter를 등록합니다.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['node_exporter:9100']

4. Grafana 대시보드 구축

4.1 데이터 소스 연결

Grafana 접속(http://localhost:3000) 후 Administration > Data sources에서 Prometheus를 추가합니다. URL에는 Docker 네트워크 내부 주소인 http://prometheus:9090을 입력합니다.

4.2 대시보드 가져오기 (Import)

일일이 그래프를 그릴 필요 없이, 커뮤니티에서 검증된 대시보드를 활용합니다. Node Exporter Full (ID: 1860) 대시보드를 Import하면 CPU 사용률, 메모리, 디스크 I/O, 네트워크 트래픽 등을 즉시 확인할 수 있습니다.

저희는 여기에 JVM Micrometer (ID: 4701) 대시보드도 추가하여 Java 애플리케이션의 Heap 메모리 상태와 GC 로그까지 통합 모니터링 환경을 구축했습니다.

5. 알림(Alerting) 설정 사례

단순한 시각화를 넘어 문제 발생 시 즉각 대응할 수 있도록 알람을 설정했습니다. 가장 유용했던 알람 규칙은 다음과 같습니다.

• HostHighCpuLoad: CPU 사용률이 5분 이상 80%를 초과할 때
• KubernetesPodNotHealthy: 특정 파드가 Running 상태가 아닐 때
• DiskSpaceRunningLow: 디스크 여유 공간이 10% 미만일 때 (로그 파일 급증 사전 대응)

이러한 알람은 Slack 웹훅과 연동하여 #ops-alert 채널로 전송되도록 설정했습니다.

6. 결론

모니터링 시스템 구축 후 장애 인지 시간이 평균 30분에서 3분 이내로 단축되었습니다. 또한, '느리다'는 막연한 느낌이 아닌 'P99 레이턴시가 500ms로 증가했다'는 정확한 데이터를 바탕으로 개발팀과 커뮤니케이션할 수 있게 되었습니다.