[Metric] 프로메테우스 + 그라파나

 

들어가며

컨테이너를 관리하는 쿠버네티스에서 항상 등장하는 것이 프로메테우스(Prometheus)와 그라파나(Grafana)입니다.두 기술은 철처히 서로 다른 역할을 하지만, 모니터링 툴로 사용하기에는 궁합이 좋습니다. 오늘은 두 가지 기술에 대해 살펴보고, 간단히 구축하는 방법까지 살펴보겠습니다.

 

프로메테우스 매트릭(Prometheus Metrics)이란?

프로메테우스(Prometheus)는 모니터링 및 알림을 위한 오픈소스 시스템으로, 시계열 데이터(time-series data)를 수집하고 저장합니다. 여기서 "매트릭(metric)"은 프로메테우스가 모니터링하는 데이터 포인트를 의미하며, 이는 시간에 따라 변경되는 특정 측정값을 나타냅니다.

프로메테우스 매트릭의 주요 특징

1. 시계열 데이터: 매트릭은 특정 시간(timestamp)에 대한 값(value)과 해당 값이 발생한 레이블(label)의 집합으로 정의됩니다.
   • 예: cpu_usage{host="server1", core="0"} 0.85 @ 1672601983
2. 레이블(Label): 매트릭에 추가 정보를 제공하는 key-value 쌍입니다. 레이블을 통해 동일한 매트릭 이름을 가진 데이터라도 구체적인 구분이 가능합니다.
   • 예: http_requests_total{method="POST", status="500"} 10
3. 다양한 유형: 프로메테우스 매트릭은 네 가지 기본 유형으로 분류됩니다.

 

프로메테우스 매트릭의 장점

• 고도로 커스터마이징 가능한 레이블: 복잡한 데이터 쿼리와 분석 가능.
• 효율적인 스토리지: 시계열 데이터를 효율적으로 저장하고 처리.
• 알림 시스템 통합: AlertManager와 함께 사용해 문제 발생 시 알림을 보낼 수 있음.

 

즉, 프로메테우스는 데이터 수집만을 담당하는 서비스입니다.

 

 

 

그라파나(Grafana)란?

그라파나(Grafana)는 데이터 시각화와 모니터링을 위한 오픈소스 플랫폼입니다. 다양한 데이터 소스에서 데이터를 가져와 대시보드를 생성하고, 시계열 데이터를 시각화하여 실시간으로 분석할 수 있도록 도와줍니다. 주로 프로메테우스(Prometheus)와 함께 사용되지만, 다른 데이터 소스와도 잘 통합됩니다.

---

그라파나의 주요 기능

1. 데이터 시각화
   • 시계열 데이터를 차트, 그래프, 테이블 형태로 시각화.
   • 데이터를 이해하기 쉽고 직관적으로 파악 가능.
2. 다양한 데이터 소스 지원
   • Prometheus, InfluxDB, Elasticsearch, OpenSearch, MySQL, PostgreSQL 등과 연동 가능.
   • 여러 데이터 소스를 한 대시보드에 통합하여 분석 가능.
3. 대시보드 생성 및 커스터마이징
   • 드래그 앤 드롭 방식으로 대시보드 생성.
   • 다양한 위젯(그래프, 게이지, 히트맵 등) 제공.
4. 알림(Alerting)
   • 특정 조건을 설정해 알림을 생성하고 이메일, Slack, PagerDuty 등으로 알림 전송.
   • 예: 서버의 CPU 사용률이 90%를 초과할 경우 알림 발송.
5. 사용자 관리 및 공유
   • 대시보드를 팀과 공유하거나 사용자별 접근 권한 설정.
   • 특정 사용자나 팀에 맞춘 대시보드 제공.
6. 플러그인 확장성
   • 수백 개의 플러그인을 설치하여 새로운 데이터 소스, 차트 유형, 패널 기능 추가 가능.

 

그라파나의 주요 활용 사례

1. 서버 및 시스템 모니터링
   • CPU, 메모리, 네트워크 사용량 추적.
   • 프로메테우스와 연동하여 서버 상태를 실시간으로 모니터링.
2. 애플리케이션 성능 관리(APM)
   • 애플리케이션의 응답 시간, 에러율, 트래픽 분석.
   • 데이터 소스로 New Relic, Jaeger 등 사용.
3. 비즈니스 데이터 시각화
   • 매출, 사용자 행동, 트랜잭션 데이터 분석.
   • MySQL, PostgreSQL 등에서 데이터 가져와 대시보드 생성.
4. 클라우드 인프라 모니터링
   • AWS, Google Cloud, Azure의 서비스 상태 및 비용 분석.
   • CloudWatch, BigQuery와 같은 클라우드 데이터 소스와 통합.

 

 

 

프로메테우스+그라파나 구축하기

Python FastAPI를 사용해서 심플한 데이터를 수집하고 그라파나에서 볼 수 있도록 하겠습니다. 먼저 로그 카운트를 세는 FastAPI 코드를 작성합니다.

from fastapi import FastAPI
from prometheus_client import Counter, generate_latest

app = FastAPI()

# Prometheus Metrics
LOG_COUNTER = Counter("log_count", "Count of specific logs")

@app.get("/")
def read_root():
    return {"message": "Hello World"}

@app.get("/metrics")
def metrics():
    # Prometheus metrics endpoint
    return generate_latest(), {"Content-Type": "text/plain; version=0.0.4"}

@app.get("/log")
def log_event():
    LOG_COUNTER.inc()  # Increment the counter
    return {"message": "Log incremented"}

프로메테우스 클라이언트와 FastAPI를 구동할 수 있는 패키지를 설치해줍니다.

pip install prometheus-client fastapi uvicorn

 

FastAPI 애플리케이션을 실행해줍니다.

uvicorn app:app --host 0.0.0.0 --port 8000

http://localhost:8000/metrics에서 프로메테우스가 수집하는 메트릭을 확인해봅니다. 제 개인적인 테스트 환경에서는 주요 가상자산에 대한 오더북 개수를 수집했습니다. 아래와 비슷하게 결과가 나와야 합니다.

process_cpu_seconds_total 4.460000000000001
# HELP process_open_fds Number of open file descriptors.
# TYPE process_open_fds gauge
process_open_fds 16.0
# HELP process_max_fds Maximum number of open file descriptors.
# TYPE process_max_fds gauge
process_max_fds 65535.0
# HELP btc_open_order BTC open order count
# TYPE btc_open_order gauge
btc_open_order 328.0
# HELP eth_open_order ETH open order count
# TYPE eth_open_order gauge
eth_open_order 220.0
# HELP xrp_open_order XRP open order count
# TYPE xrp_open_order gauge
xrp_open_order 227.0
# HELP doge_open_order DOGE open order count
# TYPE doge_open_order gauge
doge_open_order 231.0
# HELP sol_open_order SOL open order count
# TYPE sol_open_order gauge
sol_open_order 234.0

metrics의 데이터는 json형태가 아닌 plain text입니다. 만약 metrics의 데이터가 대괄호로 시작했을 때는 json으로 읽으려다가 에러가 날 수 있으니 FastAPI의 metric 라우터의 반환값을 아래와 같이 Response로 변경합니다.

from fastapi import FastAPI
from prometheus_client import generate_latest, CONTENT_TYPE_LATEST
from starlette.responses import Response

app = FastAPI()

@app.get("/metrics")
def metrics():
    # Return Prometheus metrics with explicit Content-Type
    return Response(content=generate_latest(), media_type=CONTENT_TYPE_LATEST)

 

다음으로 프로메테우스와 그라파나를 도커 컨테이너 위에 실행할 준비를 합니다. docker-compose.yml을 작성합니다.

services:
  prometheus:
    image: prom/prometheus
    container_name: prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"
    networks:
      - monitoring

  grafana:
    image: grafana/grafana
    container_name: grafana
    ports:
      - "3000:3000"
    networks:
      - monitoring

networks:
  monitoring:
    driver: bridge

 

다음으로 prometheus.yml을 작성합니다.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'fastapi'
    metrics_path: /metrics
    static_configs:
      - targets: ['host.docker.internal:8000']

 

마지막으로 Docker compose를 실행합니다.

docker-compose up -d

docker-compose ps를 통해 컨테이너가 제대로 작동하는 지 체크 합니다. 

만약 컨테이너에 문제가 있다면 docker-compose logs 혹은 docker logs prometheus 명령어에서 ERROR를 찾아야 합니다.

프로메테우스가 수집하는 컨테이너 상의 포트는 9090이며(http://localhost:9090), 그라파나를 볼 수 있는 포트는 3000입니다( http://localhost:3000). http://localhost:9090/api/v1/targets를 조회해서 health값이 "up" 상태이어야 프로메테우스가 제대로 데이터를 수집하고 있는 것입니다. 만약 "down"상태이면 lastError를 참고해서 수정해야 합니다.

permission denied 권한 문제가 나왔다면,

sudo chown -R 472:472 ./grafana-data 명령어를 통해 Grafana Docker 컨테이너가 사용하는 기본 사용자 그룹으로 변경해줍니다.

yml 파일들을 변경하고 나면 docker-compose 재시작해야 적용됩니다.

docker-compose down
docker-compose up -d

 

http://localhost:3000에 접속하여 그라파나가 정상적으로 실행되는지 확인합니다. 초기 로그인 정보는 admin/admin입니다. 첫 로그인시 변경이 필요합니다. 이 과정이 싫으시면 docker-compose.yml을 다음과 같이 수정합니다.

grafana:
    image: grafana/grafana
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=my_grafana
    volumes:
      - ./grafana-data:/var/lib/grafana
    networks:
      - monitoring

 

그라파나 설정은 두 가지입니다. 첫 번째는 data-source이고 두 번째는 dashboard setting입니다. Connections의 Data sources로 들어가셔서 기본으로 잡혀있는 connection을 프로메테우스로 설정해줍니다. 새로운 connection을 탐방하다보면 프로메테우스 말고도 수많은 데이터 소스가 있는 것을 보실 수 있습니다.

 

다음은 Dashboard로 들어가서 새로운 Dashboard를 만드시고 new panel 설정에서 Metric Browser에서 log_count를 선택하면 시각화 그래프가 나오게 됩니다.

제 예제에서는 앞서 말씀드린 것과 같이 가상자산에 대한 count를 출력합니다.

만약 metric browser에서 "log_count"라는 태그가 잡히지 않는다면, 프로메테우스에서 데이터 수집이 원활하게 안되고 있는 것이니 프로메테우스에서 데이터 수집이 잘 되고 있는지 logs와 http://localhost:9090/api/v1/targets를 다시 확인해주시면 됩니다. data-source도 확인해보세요.

그리고 query option에서 interval을 조정할 수 있고, panel option에서 Legend, tooltip, Axis, Style등 다양한 시각화 도구를 제공합니다. 아예 차트 종류를 변경할 수 있죠. Time series를 Bar chart로 변경한 모습입니다.

 

 

여기까지 간단하게 프로메테우스와 그라파나를 통한 시각화 모니터링을 만들어봤습니다.

 

 

마치며

마치는 글 전에, 프로메테우스에 대해 조금 더 알아보겠습니다. 저도 모니터링 시각화를 구축할 때 프로메테우스를 통해 데이터를 수집하는 데 애를 먹었거든요. 

먼저 프로메테우스의 데이터 타입 종류가 몇가지 있습니다. 상황에 맞는 데이터 타입을 사용해야 제대로 된 시각화 툴을 구축할 수 있습니다. 다음은 프로메테우스의 데이터 타입에 대한 설명입니다.

---

1. Counter (카운터)

설명

• 단조 증가 메트릭으로, 값이 0 이상이며 오직 증가만 가능합니다.
• 주로 이벤트 횟수를 측정하는 데 사용됩니다.
• 재시작 시 초기화될 수 있습니다.

사용 예시

# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET", status="200"} 1234
http_requests_total{method="POST", status="500"} 42

• 의미: 총 HTTP 요청 수를 상태 코드별로 구분.
• PromQL 예제:

  rate(http_requests_total[5m])  # 지난 5분 동안 초당 요청 수의 비율 계산
  

---

2. Gauge (게이지)

설명

• 값이 증가하거나 감소할 수 있는 메트릭.
• 주로 현재 상태(CPU 사용률, 메모리 사용량 등)를 측정하는 데 사용됩니다.

사용 예시

# HELP memory_usage_bytes Current memory usage in bytes
# TYPE memory_usage_bytes gauge
memory_usage_bytes 204857600

• 의미: 현재 메모리 사용량(바이트 단위).
• PromQL 예제:

  memory_usage_bytes  # 현재 메모리 사용량 조회
  

---

3. Histogram (히스토그램)

설명

• 데이터를 버킷 단위로 분포시켜 저장합니다.
• 값이 특정 범위에 얼마나 자주 나타나는지를 측정합니다.
• 요약 정보(_sum, _count, 버킷별 데이터)를 제공합니다.

사용 예시

# HELP http_request_duration_seconds HTTP request duration in seconds
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 2400
http_request_duration_seconds_bucket{le="0.5"} 3000
http_request_duration_seconds_bucket{le="1.0"} 3500
http_request_duration_seconds_bucket{le="+Inf"} 4000
http_request_duration_seconds_sum 700
http_request_duration_seconds_count 4000

• 의미:
  • le="0.1": 0.1초 이하로 처리된 요청 수는 2400.
  • http_request_duration_seconds_sum: 모든 요청의 총 시간 합계(초 단위).
  • http_request_duration_seconds_count: 요청 총 개수.
• PromQL 예제:
  • 의미: 지난 5분 동안 요청의 평균 처리 시간.
• rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])

---

4. Summary (요약)

설명

• 히스토그램과 유사하지만 쿼타일(Quantile) 데이터를 계산합니다.
• 버킷 대신 직접적인 통계 값(예: 0.5-백분위수, 0.9-백분위수)을 제공합니다.
• 정확한 계산이 가능하지만, 메모리와 CPU 사용량이 높을 수 있습니다.

사용 예시

# HELP http_request_duration_seconds HTTP request duration in seconds
# TYPE http_request_duration_seconds summary
http_request_duration_seconds{quantile="0.5"} 0.05
http_request_duration_seconds{quantile="0.9"} 0.1
http_request_duration_seconds{quantile="0.99"} 0.2
http_request_duration_seconds_sum 500
http_request_duration_seconds_count 10000

• 의미:
  • quantile="0.5": 요청 처리 시간의 50%가 0.05초 이하.
  • quantile="0.99": 요청 처리 시간의 99%가 0.2초 이하.
• PromQL 예제:
  • 의미: 99-백분위수 요청 처리 시간.
• http_request_duration_seconds{quantile="0.99"}

---

데이터 타입 비교 및 선택 가이드

타입	주요 특징	사용 사례
Counter	단조 증가, 값 초기화 가능	요청 수, 오류 수, 처리된 작업 수 측정
Gauge	값 증가/감소 가능, 현재 상태 측정	CPU/메모리 사용량, 현재 온도, 활성 연결 수
Histogram	버킷 분포 데이터, _sum와 _count 제공	요청 처리 시간 분포, 파일 크기 분포
Summary	쿼타일 기반 요약, 정확한 계산	응답 시간의 50%, 90%, 99% 백분위수 계산

 

 

프로메테우스와 그라파나를 이용하면 강력하고 편한 시각화 툴을 사용할 수 있습니다. 초기 구축이 조금 까다롭긴 하지만, 간단한 예제로부터 시작해보세요! 이후 여러분들이 하는 프로젝트에서 보고 싶은 데이터들을 모두 추가해서 실시간으로 쌓이는 데이터 변화를 감상하시면 됩니다.