Grafana와 Prometheus 모니터링 완벽 가이드

DevOps 환경에서 필수적인 Prometheus와 Grafana를 활용한 모니터링 시스템 구축 방법을 알아봅니다. 메트릭 수집부터 대시보드 생성, 알림 설정까지 실무에서 바로 적용할 수 있는 내용을 담았습니다.

---

목차

1. Prometheus와 Grafana 개념
2. additional_services에 모니터링 추가
3. Grafana 대시보드 접근
4. 노드 메트릭 확인하기
5. 커스텀 대시보드 만들기
6. 알림 설정하기

---

1. Prometheus와 Grafana 개념

어느 날 김개발 씨가 운영 중인 서비스에서 갑자기 응답 속도가 느려졌다는 보고를 받았습니다. 하지만 어디서 문제가 발생했는지 알 수 없었습니다.

로그를 뒤져봐도 원인을 찾기 어려웠습니다. 이때 선배 박시니어 씨가 다가와 말했습니다.

"모니터링 시스템을 구축했으면 바로 알 수 있었을 텐데요."

Prometheus는 시계열 데이터베이스로, 서버나 애플리케이션의 메트릭을 수집하고 저장하는 도구입니다. Grafana는 이렇게 수집된 데이터를 시각적으로 보여주는 대시보드 도구입니다.

마치 자동차의 계기판처럼, 시스템의 상태를 한눈에 파악할 수 있게 해줍니다. 이 둘을 함께 사용하면 시스템 모니터링의 강력한 조합이 완성됩니다.

다음 코드를 살펴봅시다.

# docker-compose.yml - 모니터링 스택 기본 구성
version: '3.8'
services:
  # Prometheus: 메트릭 수집 및 저장
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml

  # Grafana: 시각화 대시보드
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 어느 날 새벽, 갑자기 전화가 울렸습니다.

"김 개발자님, 서비스가 느려졌다는 고객 문의가 폭주하고 있어요!" 급하게 노트북을 켜고 서버에 접속했지만, 어디서부터 봐야 할지 막막했습니다. CPU 사용량인지, 메모리 문제인지, 네트워크 지연인지 하나하나 명령어를 입력해가며 확인해야 했습니다.

문제를 찾는 데만 30분이 넘게 걸렸습니다. 다음 날 출근해서 선배 박시니어 씨에게 이 이야기를 했더니, 고개를 저으며 말했습니다.

"모니터링 시스템만 있었어도 5분 만에 원인을 찾았을 거예요." 그렇다면 모니터링 시스템이란 정확히 무엇일까요? 쉽게 비유하자면, 모니터링 시스템은 마치 종합병원의 환자 모니터와 같습니다.

환자의 심박수, 혈압, 체온 등을 실시간으로 보여주는 것처럼, 서버의 CPU 사용률, 메모리 사용량, 응답 시간 등을 실시간으로 보여줍니다. 의사가 모니터를 보고 환자 상태를 즉시 파악하듯, 개발자도 대시보드를 보고 서버 상태를 한눈에 알 수 있습니다.

이 모니터링 시스템의 핵심 구성 요소가 바로 Prometheus와 Grafana입니다. Prometheus는 그리스 신화에서 인류에게 불을 가져다준 신의 이름에서 따왔습니다.

2012년 SoundCloud에서 개발되어 현재는 Cloud Native Computing Foundation의 두 번째 졸업 프로젝트가 되었습니다. Prometheus의 핵심 역할은 메트릭 수집입니다.

일정 간격으로 대상 시스템에 접근해서 현재 상태 데이터를 가져옵니다. 이것을 Pull 방식이라고 합니다.

수집된 데이터는 시계열 데이터베이스에 저장됩니다. 시계열 데이터란 시간에 따라 변하는 데이터를 의미합니다.

"오전 10시에 CPU 사용률 45%, 오전 10시 1분에 CPU 사용률 47%"처럼 시간과 함께 기록되는 데이터입니다. 이런 데이터가 쌓이면 추세를 분석하고 이상 징후를 감지할 수 있습니다.

Grafana는 이렇게 수집된 데이터를 아름답고 직관적인 그래프로 보여줍니다. Prometheus가 데이터를 모으는 수집가라면, Grafana는 그 데이터를 예술 작품처럼 표현하는 화가와 같습니다.

선 그래프, 막대 그래프, 게이지, 히트맵 등 다양한 시각화 방식을 제공합니다. 둘의 관계를 정리하면 이렇습니다.

Prometheus가 데이터를 수집하고 저장하면, Grafana가 그 데이터를 조회해서 화면에 그려줍니다. 마치 창고지기와 전시회 큐레이터의 관계와 비슷합니다.

위의 코드를 살펴보면, Docker Compose를 사용해 두 서비스를 함께 실행하는 설정입니다. Prometheus는 9090 포트에서, Grafana는 3000 포트에서 각각 동작합니다.

실제 운영 환경에서도 이처럼 컨테이너로 배포하는 경우가 많습니다. 김개발 씨는 박시니어 씨의 설명을 듣고 눈이 반짝였습니다.

"그러니까 이 두 가지만 설치하면 서버 상태를 실시간으로 볼 수 있는 거군요!" 박시니어 씨가 고개를 끄덕였습니다. "맞아요.

이제 직접 구축해봅시다."

실전 팁

💡 - Prometheus는 Pull 방식으로 동작하므로 모니터링 대상에서 메트릭 엔드포인트를 노출해야 합니다

• Grafana는 Prometheus 외에도 MySQL, PostgreSQL, Elasticsearch 등 다양한 데이터 소스를 지원합니다
• 프로덕션 환경에서는 반드시 Grafana 기본 비밀번호를 변경하세요

---

2. additional services에 모니터링 추가

김개발 씨가 모니터링의 필요성을 깨달은 후, 본격적으로 설정에 들어갔습니다. 하지만 기존 서비스에 모니터링을 어떻게 추가해야 할지 막막했습니다.

박시니어 씨가 docker-compose 파일을 열며 말했습니다. "기존 서비스 구성에 모니터링 스택을 추가하는 건 생각보다 간단해요."

기존 Docker Compose 환경에 모니터링 서비스를 추가하려면 additional_services 개념을 이해해야 합니다. Prometheus, Grafana, 그리고 시스템 메트릭을 수집하는 Node Exporter를 함께 구성합니다.

각 서비스가 같은 네트워크에서 통신할 수 있도록 설정하는 것이 핵심입니다.

다음 코드를 살펴봅시다.

# docker-compose.monitoring.yml
version: '3.8'
services:
  prometheus:
    image: prom/prometheus:v2.45.0
    container_name: prometheus
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=15d'
    ports:
      - "9090:9090"
    networks:
      - monitoring
    restart: unless-stopped

  grafana:
    image: grafana/grafana:10.0.0
    container_name: grafana
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=secure_password
      - GF_USERS_ALLOW_SIGN_UP=false
    ports:
      - "3000:3000"
    networks:
      - monitoring
    depends_on:
      - prometheus
    restart: unless-stopped

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    ports:
      - "9100:9100"
    networks:
      - monitoring
    restart: unless-stopped

networks:
  monitoring:
    driver: bridge

volumes:
  prometheus_data:
  grafana_data:

김개발 씨는 회사에서 운영 중인 서비스의 docker-compose.yml 파일을 열었습니다. 웹 서버, 데이터베이스, 캐시 서버 등이 이미 정의되어 있었습니다.

여기에 모니터링 서비스를 어떻게 추가해야 할까요? 박시니어 씨가 조언했습니다.

"기존 파일을 수정하는 것보다, 별도의 모니터링 전용 compose 파일을 만드는 게 좋아요. 관심사의 분리라고 할 수 있죠." docker-compose.monitoring.yml이라는 별도 파일을 만들면 모니터링 관련 설정을 독립적으로 관리할 수 있습니다.

필요할 때만 모니터링을 켜거나 끌 수 있고, 설정 변경도 더 안전합니다. 코드의 첫 번째 서비스인 Prometheus 설정을 살펴봅시다.

volumes 항목에서 설정 파일과 데이터 저장소를 연결합니다. prometheus.yml은 어떤 대상에서 메트릭을 수집할지 정의하는 설정 파일입니다.

storage.tsdb.retention.time=15d 옵션은 데이터를 15일간 보관하겠다는 의미입니다. 서버 용량에 따라 이 값을 조절하면 됩니다.

두 번째 서비스인 Grafana 설정에서 주목할 점은 환경 변수입니다. GF_SECURITY_ADMIN_PASSWORD로 관리자 비밀번호를 설정합니다.

반드시 기본값인 admin에서 변경해야 합니다. GF_USERS_ALLOW_SIGN_UP=false는 회원가입 기능을 비활성화합니다.

내부 모니터링 시스템에 외부인이 가입할 필요는 없으니까요. 세 번째 서비스인 Node Exporter는 중요한 역할을 합니다.

서버의 하드웨어와 운영체제 수준의 메트릭을 수집합니다. CPU 사용률, 메모리 사용량, 디스크 I/O, 네트워크 트래픽 등을 측정합니다.

volumes 설정에서 호스트 시스템의 /proc, /sys, / 디렉토리를 읽기 전용으로 마운트합니다. 이를 통해 컨테이너 내부에서 호스트 시스템의 정보를 읽을 수 있습니다.

networks 설정이 왜 중요할까요? 같은 Docker 네트워크에 있어야 컨테이너들이 서로 통신할 수 있습니다.

Prometheus가 Node Exporter에서 메트릭을 가져오려면, 그리고 Grafana가 Prometheus에 쿼리를 날리려면 같은 네트워크에 있어야 합니다. depends_on 설정도 눈여겨볼 필요가 있습니다.

Grafana는 Prometheus에 의존하므로, Prometheus가 먼저 시작된 후에 Grafana가 시작됩니다. 순서가 중요한 서비스들 사이의 관계를 정의하는 것입니다.

이제 실행해볼 차례입니다. 터미널에서 다음 명령어를 입력합니다.

docker-compose -f docker-compose.monitoring.yml up -d 김개발 씨가 명령어를 실행하자 세 개의 컨테이너가 차례로 시작되었습니다. "이제 기본 설정은 끝났어요.

다음은 Prometheus가 어디서 메트릭을 수집할지 알려줘야 해요." 박시니어 씨가 prometheus.yml 파일을 열었습니다.

실전 팁

💡 - 프로덕션 환경에서는 반드시 볼륨을 사용해 데이터를 영구 저장하세요

• restart: unless-stopped 옵션으로 서버 재시작 시에도 자동으로 컨테이너가 실행되도록 설정하세요
• 메모리가 제한된 환경에서는 Prometheus의 retention 기간을 줄이는 것이 좋습니다

---

3. Grafana 대시보드 접근

모니터링 스택을 실행한 김개발 씨는 드디어 Grafana에 접속해볼 시간입니다. 브라우저를 열고 주소창에 localhost:3000을 입력했습니다.

로그인 화면이 나타났습니다. "여기서부터가 진짜 시작이에요." 박시니어 씨가 말했습니다.

Grafana 대시보드에 접근하려면 먼저 데이터 소스를 설정해야 합니다. Prometheus를 데이터 소스로 추가하면 수집된 메트릭을 Grafana에서 조회할 수 있습니다.

기본 로그인 후 Connection 설정에서 Prometheus URL을 입력하는 것이 첫 번째 단계입니다.

다음 코드를 살펴봅시다.

# prometheus.yml - Prometheus 설정 파일
global:
  scrape_interval: 15s          # 메트릭 수집 주기
  evaluation_interval: 15s      # 규칙 평가 주기

alerting:
  alertmanagers:
    - static_configs:
        - targets: []

rule_files: []

scrape_configs:
  # Prometheus 자체 메트릭
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  # Node Exporter 메트릭
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

  # 애플리케이션 메트릭 (예시)
  - job_name: 'webapp'
    static_configs:
      - targets: ['webapp:8080']
    metrics_path: '/metrics'

김개발 씨가 브라우저에 **http://localhost:3000**을 입력했습니다. Grafana의 깔끔한 로그인 화면이 나타났습니다.

초기 아이디와 비밀번호는 docker-compose 파일에서 설정한 대로 입력합니다. 로그인에 성공하면 Grafana의 홈 화면이 나타납니다.

아직은 비어있는 캔버스와 같습니다. 이제 이 캔버스에 그림을 그리기 위한 물감, 즉 데이터 소스를 연결해야 합니다.

왼쪽 메뉴에서 Connections 아이콘을 클릭합니다. 기어 모양 아이콘입니다.

Data sources를 선택하고 Add data source 버튼을 누릅니다. 수많은 데이터 소스 목록 중에서 Prometheus를 선택합니다.

설정 화면에서 가장 중요한 것은 URL 입력입니다. 여기서 많은 초보자들이 실수를 합니다.

localhost:9090이 아니라 **http://prometheus:9090**을 입력해야 합니다. 왜 그럴까요?

Docker 네트워크 안에서는 컨테이너 이름이 호스트명 역할을 합니다. Grafana 컨테이너 입장에서 localhost는 자기 자신입니다.

Prometheus 컨테이너에 접근하려면 컨테이너 이름인 prometheus를 사용해야 합니다. 이것은 Docker 네트워킹의 기본 개념입니다.

URL을 입력한 후 Save & test 버튼을 누릅니다. "Data source is working"이라는 녹색 메시지가 나타나면 성공입니다.

만약 에러가 발생한다면 Prometheus 컨테이너가 정상적으로 실행 중인지, 네트워크 설정이 올바른지 확인해야 합니다. 이제 prometheus.yml 파일을 살펴봅시다.

이 파일은 Prometheus에게 "어디서 무엇을 수집할지" 알려주는 설정 파일입니다. scrape_interval: 15s는 15초마다 메트릭을 수집하겠다는 의미입니다.

너무 짧으면 부하가 커지고, 너무 길면 세밀한 변화를 놓칠 수 있습니다. 15초는 적절한 기본값입니다.

scrape_configs 섹션이 핵심입니다. 여기서 모니터링 대상을 정의합니다.

job_name은 대상을 구분하는 이름표입니다. targets는 실제 접근할 주소입니다.

node-exporter:9100은 Node Exporter 컨테이너의 9100 포트를 의미합니다. 여기서도 마찬가지로 Docker 네트워크 안에서는 컨테이너 이름을 사용합니다.

webapp:8080 같은 설정은 여러분의 애플리케이션을 모니터링할 때 사용합니다. 물론 애플리케이션에서 /metrics 엔드포인트를 노출해야 합니다.

이 부분은 나중에 더 자세히 다루겠습니다. 김개발 씨가 데이터 소스 설정을 마치고 뿌듯한 표정을 지었습니다.

"이제 데이터가 들어오는 거죠?" 박시니어 씨가 고개를 끄덕였습니다. "맞아요.

이제 실제 메트릭을 확인해볼 시간이에요."

실전 팁

💡 - Docker 환경에서는 컨테이너 이름을 호스트명으로 사용합니다. localhost가 아닌 컨테이너 이름을 URL에 입력하세요

• scrape_interval은 모니터링 대상의 특성에 따라 조절하세요. 빠르게 변하는 메트릭은 더 짧은 주기가 필요합니다
• Prometheus 설정 변경 후에는 컨테이너를 재시작해야 적용됩니다

---

4. 노드 메트릭 확인하기

데이터 소스 설정을 마친 김개발 씨는 이제 실제 데이터를 보고 싶어졌습니다. "서버 CPU 사용률이 얼마인지 어떻게 확인하죠?" 박시니어 씨가 Explore 메뉴를 클릭하며 말했습니다.

"PromQL이라는 쿼리 언어를 사용하면 돼요. 어렵지 않아요."

Node Exporter가 수집하는 메트릭을 확인하려면 PromQL(Prometheus Query Language)을 사용합니다. CPU 사용률, 메모리 사용량, 디스크 I/O 등 시스템의 핵심 지표를 쿼리로 조회할 수 있습니다.

Grafana의 Explore 기능을 통해 쿼리를 테스트하고 결과를 확인합니다.

다음 코드를 살펴봅시다.

# 자주 사용하는 PromQL 쿼리 모음

# CPU 사용률 (%)
100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# 메모리 사용률 (%)
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# 디스크 사용률 (%)
(1 - (node_filesystem_avail_bytes{fstype!="tmpfs"} / node_filesystem_size_bytes{fstype!="tmpfs"})) * 100

# 네트워크 수신 트래픽 (bytes/sec)
irate(node_network_receive_bytes_total{device!="lo"}[5m])

# 네트워크 송신 트래픽 (bytes/sec)
irate(node_network_transmit_bytes_total{device!="lo"}[5m])

# 시스템 로드 평균 (1분)
node_load1

# 열린 파일 디스크립터 수
node_filefd_allocated

김개발 씨가 Grafana 왼쪽 메뉴에서 Explore 아이콘을 클릭했습니다. 나침반 모양의 아이콘입니다.

여기서 PromQL 쿼리를 직접 입력하고 결과를 확인할 수 있습니다. 상단의 데이터 소스 드롭다운에서 방금 설정한 Prometheus를 선택합니다.

그리고 쿼리 입력창에 node_cpu_seconds_total을 입력하고 실행해봅니다. 화면에 여러 개의 시계열 데이터가 나타났습니다.

하지만 숫자들이 매우 크고 계속 증가합니다. "이게 CPU 사용률인가요?

숫자가 너무 이상한데요." 김개발 씨가 의아해했습니다. 박시니어 씨가 설명했습니다.

"이건 CPU가 각 모드에서 보낸 누적 시간이에요. 우리가 원하는 건 퍼센트 단위의 사용률이죠.

그래서 계산이 필요해요." PromQL은 단순히 데이터를 조회하는 것을 넘어, 데이터를 가공하고 계산할 수 있는 강력한 쿼리 언어입니다. SQL에서 SELECT만 하는 게 아니라 SUM, AVG 같은 함수를 쓰는 것과 비슷합니다.

CPU 사용률 쿼리를 분석해봅시다. **irate(node_cpu_seconds_total{mode="idle"}[5m])**에서 irate 함수는 초당 변화율을 계산합니다.

[5m]은 최근 5분간의 데이터를 사용한다는 의미입니다. {mode="idle"}은 CPU가 아무 일도 안 하고 있는 idle 상태만 필터링합니다.

idle 상태의 비율을 알면, 100에서 빼면 실제 사용률이 됩니다. 100 - (idle 비율) = 사용률.

이것이 첫 번째 쿼리의 핵심 로직입니다. 메모리 사용률 쿼리는 더 직관적입니다.

node_memory_MemAvailable_bytes는 사용 가능한 메모리, node_memory_MemTotal_bytes는 전체 메모리입니다. (1 - 사용가능/전체) * 100으로 사용률을 계산합니다.

디스크 사용률도 같은 원리입니다. 다만 fstype!="tmpfs" 조건이 추가됩니다.

tmpfs는 메모리 기반의 임시 파일 시스템이므로 일반적인 디스크 모니터링에서는 제외합니다. 네트워크 트래픽 쿼리에서 device!="lo" 조건은 루프백 인터페이스를 제외합니다.

lo는 자기 자신과 통신하는 가상 인터페이스이므로 실제 네트워크 트래픽에는 포함시키지 않습니다. 김개발 씨가 CPU 사용률 쿼리를 입력하고 실행했습니다.

드디어 익숙한 퍼센트 값이 그래프로 나타났습니다. "오, 지금 CPU 사용률이 23%네요!" 실시간으로 변하는 그래프를 보며 감탄했습니다.

박시니어 씨가 덧붙였습니다. "Explore는 쿼리를 테스트하는 용도예요.

실제로 모니터링할 때는 대시보드에 패널로 추가해야 해요. 그래야 여러 지표를 한 화면에서 볼 수 있죠."

실전 팁

💡 - irate는 순간 변화율, rate는 평균 변화율을 계산합니다. 스파이크를 감지하려면 irate가 좋습니다

• [5m] 같은 범위 선택자는 쿼리 결과의 부드러움에 영향을 줍니다. 범위가 넓을수록 그래프가 부드럽습니다
• Metrics browser 기능을 활용하면 사용 가능한 메트릭 목록을 쉽게 탐색할 수 있습니다

---

5. 커스텀 대시보드 만들기

Explore에서 쿼리 테스트를 마친 김개발 씨는 이제 본격적으로 대시보드를 만들고 싶어졌습니다. "필요한 지표들을 한 화면에서 보고 싶어요." 박시니어 씨가 미소 지었습니다.

"좋아요. 우리만의 커스텀 대시보드를 만들어봅시다.

아니면 커뮤니티에서 만들어놓은 걸 가져올 수도 있어요."

Grafana에서는 직접 대시보드를 생성하거나 커뮤니티 대시보드를 임포트할 수 있습니다. 패널을 추가하고 PromQL 쿼리를 연결하면 시각화가 완성됩니다.

Node Exporter용 대시보드는 ID 1860이 가장 인기 있으며, 임포트 기능으로 쉽게 가져올 수 있습니다.

다음 코드를 살펴봅시다.

# Grafana 대시보드 JSON 설정 예시 (일부)
{
  "dashboard": {
    "title": "서버 모니터링 대시보드",
    "panels": [
      {
        "title": "CPU 사용률",
        "type": "gauge",
        "targets": [
          {
            "expr": "100 - (avg(irate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)",
            "refId": "A"
          }
        ],
        "fieldConfig": {
          "defaults": {
            "unit": "percent",
            "max": 100,
            "thresholds": {
              "steps": [
                { "value": 0, "color": "green" },
                { "value": 70, "color": "yellow" },
                { "value": 90, "color": "red" }
              ]
            }
          }
        }
      },
      {
        "title": "메모리 사용량",
        "type": "timeseries",
        "targets": [
          {
            "expr": "(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100",
            "refId": "A"
          }
        ]
      }
    ]
  }
}

김개발 씨가 Grafana 왼쪽 메뉴에서 Dashboards 아이콘을 클릭했습니다. 사각형 네 개가 모인 모양입니다.

New 버튼을 누르고 New Dashboard를 선택합니다. 빈 대시보드가 나타났습니다.

Add visualization 버튼을 클릭합니다. 데이터 소스로 Prometheus를 선택하면 패널 편집 화면이 나타납니다.

하단의 쿼리 입력창에 CPU 사용률 쿼리를 입력합니다. 우측 패널에서 Visualization 타입을 선택할 수 있습니다.

Time series는 선 그래프, Gauge는 게이지, Stat은 단일 숫자 표시입니다. CPU 사용률은 Gauge 타입이 직관적입니다.

Field 탭에서 세부 설정을 합니다. Unit을 Percent로 설정하고, Min은 0, Max는 100으로 지정합니다.

Thresholds에서 색상 기준을 설정합니다. 70% 미만은 녹색, 70-90%는 노란색, 90% 이상은 빨간색으로 설정하면 위험 수준을 한눈에 알 수 있습니다.

패널 제목을 "CPU 사용률"로 입력하고 Apply 버튼을 누릅니다. 대시보드에 첫 번째 패널이 추가되었습니다.

같은 방식으로 메모리, 디스크, 네트워크 패널을 추가합니다. 하지만 박시니어 씨가 더 빠른 방법을 알려주었습니다.

"처음부터 다 만들 필요 없어요. 커뮤니티에서 이미 잘 만들어놓은 대시보드가 있거든요." 왼쪽 메뉴에서 Dashboards > New > Import를 선택합니다.

Import via grafana.com 입력창에 1860을 입력하고 Load 버튼을 누릅니다. 1860은 Node Exporter Full 대시보드의 ID입니다.

Grafana 커뮤니티에서 가장 인기 있는 Node Exporter 대시보드입니다. CPU, 메모리, 디스크, 네트워크 등 모든 시스템 메트릭을 아름답게 시각화해놓았습니다.

데이터 소스로 Prometheus를 선택하고 Import 버튼을 누릅니다. 순식간에 수십 개의 패널이 포함된 전문적인 대시보드가 완성되었습니다.

김개발 씨가 감탄했습니다. "와, 이걸 직접 만들려면 며칠은 걸렸을 텐데요!" 물론 임포트한 대시보드도 수정할 수 있습니다.

필요 없는 패널은 삭제하고, 위치를 재배치하고, 새 패널을 추가할 수 있습니다. 회사의 필요에 맞게 커스터마이징하면 됩니다.

대시보드 상단의 Save 아이콘을 클릭해서 저장합니다. 폴더를 지정하고 이름을 입력하면 됩니다.

이제 언제든 이 대시보드에 접근해서 서버 상태를 확인할 수 있습니다.

실전 팁

💡 - grafana.com/grafana/dashboards에서 다양한 커뮤니티 대시보드를 검색할 수 있습니다

• 자주 보는 대시보드는 즐겨찾기(별표)로 설정하세요
• Variables 기능을 활용하면 하나의 대시보드로 여러 서버를 모니터링할 수 있습니다

---

6. 알림 설정하기

대시보드를 완성한 김개발 씨는 한 가지 걱정이 생겼습니다. "24시간 대시보드를 쳐다보고 있을 수는 없잖아요.

문제가 생기면 자동으로 알려주는 기능은 없나요?" 박시니어 씨가 고개를 끄덕였습니다. "당연히 있죠.

Grafana Alerting 기능을 설정해봅시다."

Grafana의 Alerting 기능을 사용하면 특정 조건이 충족될 때 자동으로 알림을 받을 수 있습니다. Alert rule을 정의하고, Contact point로 Slack이나 이메일 등 알림 채널을 설정합니다.

CPU 사용률이 90%를 초과하면 Slack으로 메시지가 오도록 구성할 수 있습니다.

다음 코드를 살펴봅시다.

# Grafana Alert Rule 설정 예시 (YAML 형식)
apiVersion: 1
groups:
  - name: 서버_알림_그룹
    folder: 알림
    interval: 1m
    rules:
      - uid: cpu_high_alert
        title: CPU 사용률 높음
        condition: C
        data:
          - refId: A
            datasourceUid: prometheus
            model:
              expr: 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
          - refId: C
            datasourceUid: __expr__
            model:
              type: threshold
              expression: A
              conditions:
                - evaluator:
                    type: gt
                    params: [90]
        for: 5m
        annotations:
          summary: "CPU 사용률이 90%를 초과했습니다"
          description: "현재 CPU 사용률: {{ $values.A }}%"
        labels:
          severity: critical

# Contact Point 설정 (Slack)
contactPoints:
  - name: slack-alerts
    receivers:
      - uid: slack_receiver
        type: slack
        settings:
          url: "https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
          channel: "#alerts"
          title: "[{{ .Status }}] {{ .CommonLabels.alertname }}"

김개발 씨는 새벽에 전화 받았던 그 날을 떠올렸습니다. 만약 그때 알림 시스템이 있었다면 문제가 심각해지기 전에 대응할 수 있었을 것입니다.

선제적 대응과 사후 대응의 차이는 큽니다. Grafana 왼쪽 메뉴에서 Alerting 아이콘을 클릭합니다.

종 모양 아이콘입니다. 먼저 Contact points를 설정해야 합니다.

알림을 어디로 보낼지 정하는 것입니다. Contact points 메뉴에서 Add contact point 버튼을 클릭합니다.

이름을 입력하고 Integration 타입을 선택합니다. Slack, Email, Discord, PagerDuty, Microsoft Teams 등 다양한 옵션이 있습니다.

Slack을 선택했다면 Webhook URL을 입력해야 합니다. Slack에서 앱을 만들고 Incoming Webhook을 활성화하면 URL을 받을 수 있습니다.

채널명도 지정합니다. Test 버튼으로 테스트 메시지를 보내서 정상 작동하는지 확인합니다.

이제 Alert rules를 만들 차례입니다. Alert rules 메뉴에서 New alert rule 버튼을 클릭합니다.

첫 번째 섹션에서 쿼리와 조건을 정의합니다. 데이터 소스로 Prometheus를 선택하고, CPU 사용률 쿼리를 입력합니다.

그 아래에서 Threshold 조건을 추가합니다. "값이 90보다 크면"이라고 설정합니다.

두 번째 섹션에서 평가 주기를 설정합니다. Evaluate every는 얼마나 자주 조건을 확인할지, for는 조건이 얼마나 지속되어야 알림을 보낼지입니다.

여기서 for 설정이 중요합니다. 만약 for를 설정하지 않으면, 순간적인 스파이크에도 알림이 발생합니다.

CPU가 잠깐 90%를 찍었다가 바로 내려갔는데도 알림이 오면 피로해집니다. for: 5m으로 설정하면 5분 동안 지속될 때만 알림이 갑니다.

세 번째 섹션에서 알림 메시지를 작성합니다. Summary에는 간단한 제목, Description에는 상세 내용을 입력합니다.

{{ $values.A }} 같은 템플릿 변수를 사용하면 실제 값이 메시지에 포함됩니다. 네 번째 섹션에서 아까 만든 Contact point를 선택합니다.

이제 조건이 충족되면 해당 채널로 알림이 전송됩니다. 김개발 씨가 설정을 마치고 저장했습니다.

테스트를 위해 일부러 CPU 부하를 주는 스크립트를 실행해봤습니다. 5분 후, Slack 채널에 알림이 도착했습니다.

"[FIRING] CPU 사용률 높음 - 현재 CPU 사용률: 94.2%" 박시니어 씨가 어깨를 두드렸습니다. "이제 새벽에 고객 전화로 깨는 일은 없을 거예요.

문제가 생기면 알림이 먼저 올 테니까요." 김개발 씨는 마음이 한결 편해졌습니다. 하지만 주의할 점도 있습니다.

알림 임계값을 너무 낮게 설정하면 알림 피로가 옵니다. 하루에 수십 건의 알림이 오면 중요한 알림도 무시하게 됩니다.

반대로 너무 높게 설정하면 정작 문제가 생겼을 때 알림이 안 옵니다. 적절한 임계값을 찾는 것도 운영 노하우입니다.

실전 팁

💡 - 알림 피로를 줄이기 위해 임계값과 for 시간을 적절히 조절하세요

• 심각도에 따라 다른 채널로 알림을 보내는 것이 좋습니다. critical은 전화/SMS, warning은 Slack
• Notification policies를 활용하면 시간대별, 팀별로 다른 알림 정책을 설정할 수 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!