# Prometheus (프로메테우스)

## 1. 개요
[[Prometheus]]는 SoundCloud에서 개발하여 현재는 [[CNCF]](Cloud Native Computing Foundation)의 졸업(Graduated) 프로젝트로 관리되고 있는 오픈소스 시스템 모니터링 및 알림 툴킷입니다. 주로 시계열 데이터([[TSDB]])를 수집하고 저장하며, 강력한 쿼리 언어인 PromQL을 통해 시스템의 상태를 분석하고 이상 징후를 감지하는 데 사용됩니다. 특히 동적인 환경의 컨테이너 오케스트레이션 도구인 [[Kubernetes]](쿠버네티스)와 높은 호환성을 가져, 현대적인 클라우드 네이티브 인프라의 표준 모니터링 솔루션으로 자리 잡고 있습니다.

## 2. 핵심 아키텍처 및 동작 원리

### 2.1 Pull 방식의 데이터 수집
Prometheus의 가장 큰 특징은 대상 서버로부터 데이터를 직접 가져오는 **Pull 방식**을 채택했다는 점입니다. 대상 서버(Target)는 특정 HTTP 엔드포인트(주로 `/metrics`)에 현재 상태 값을 노출하고, Prometheus 서버가 설정된 주기마다 해당 엔드포인트에 접속하여 데이터를 긁어오는(Scrape) 방식입니다.

| 구분 | Push 방식 (전통적 방식) | Pull 방식 (Prometheus 방식) |
| :--- | :--- | :--- |
| **데이터 흐름** | 대상 $\rightarrow$ 모니터링 서버 | 모니터링 서버 $\rightarrow$ 대상 |
| **서버 부하** | 대량의 요청이 한꺼번에 몰릴 수 있음 | 서버가 수집 주기를 제어하여 부하 조절 가능 |
| **상태 확인** | 대상이 죽었는지 알기 위해 별도 헬스체크 필요 | 수집 시도 실패 시 즉시 대상의 다운 상태 감지 가능 |
| **설정 위치** | 각 대상 서버에 서버 주소 설정 필요 | 서버 측에서 대상 리스트를 관리 |

### 2.2 시계열 데이터베이스 (TSDB)
Prometheus는 **[[TSDB]](Time Series Database)**를 사용합니다. 시계열 데이터란 시간의 흐름에 따라 기록된 값의 집합을 의미하며, `메트릭 이름{라벨=값} 값 타임스탬프` 형태로 저장됩니다. 이는 일반적인 관계형 데이터베이스(RDBMS)보다 쓰기 성능이 매우 뛰어나며, 시간 범위 기반의 집계 연산에 최적화되어 있습니다.

### 2.3 서비스 디스커버리 (Service Discovery)
클라우드 환경에서는 인스턴스가 빈번하게 생성되고 삭제됩니다. Prometheus는 **서비스 디스커버리(Service Discovery)** 기능을 통해 [[Kubernetes]] API나 AWS, GCP 등의 API와 연동하여 모니터링 대상의 IP와 포트를 자동으로 찾아내고 수집 대상 리스트를 실시간으로 업데이트합니다.

## 3. 주요 구성 요소

### 3.1 Prometheus 서버
- **Retrieval**: 설정된 대상으로부터 데이터를 수집하는 엔진입니다.
- **Storage**: 수집된 데이터를 로컬 디스크의 [[TSDB]]에 저장합니다.
- **PromQL Engine**: 사용자가 입력한 쿼리를 해석하여 데이터를 조회하고 계산합니다.

### 3.2 Exporters
Prometheus가 직접 메트릭을 노출하지 않는 소프트웨어(예: Linux 커널, MySQL, Redis)를 위해, 해당 데이터를 Prometheus 형식으로 변환하여 노출해주는 대리자 역할을 합니다.
- **Node Exporter**: 하드웨어 및 OS 메트릭(CPU, 메모리, 디스크 사용량 등) 수집.
- **JMX Exporter**: Java 애플리케이션의 JVM 메트릭 수집.

### 3.3 Alertmanager
Prometheus 서버에서 설정한 알림 규칙(Alerting Rule)에 의해 발생한 알림을 처리합니다. 중복 알림을 그룹화하고, 지정된 경로(Slack, Email, PagerDuty 등)로 전송하는 역할을 수행합니다.

### 3.4 Pushgateway
Pull 방식의 한계로 인해 수집 주기보다 짧게 실행되고 종료되는 **단기 실행 작업(Short-lived jobs/Batch jobs)**의 메트릭을 수집하기 위한 중간 저장소입니다. 작업이 Pushgateway에 데이터를 밀어 넣으면, Prometheus 서버가 이를 Pull 해갑니다.

## 4. 메트릭 타입 (Metric Types)

Prometheus는 데이터의 성격에 따라 네 가지 주요 메트릭 타입을 제공합니다.

1. **Counter**: 누적 합계 값입니다. 시간이 지남에 따라 증가만 하며, 시스템 재시작 시 0으로 초기화됩니다. 누적 값 자체보다는 `rate()`나 `increase()` 함수를 사용하여 **특정 기간 동안의 변화율(증가분)**을 측정하는 것이 핵심 활용법입니다.
2. **Gauge**: 현재 시점의 값입니다. 증가하거나 감소할 수 있습니다.
3. **Histogram**: 관찰된 값의 빈도를 버킷(Bucket) 단위로 측정합니다. 응답 시간의 분포나 백분위수(Percentile) 계산에 사용됩니다.
4. **Summary**: Histogram과 유사하지만, 서버 측이 아닌 클라이언트 측에서 백분위수를 계산하여 제공합니다.

### [표] 메트릭 타입별 실제 사용 사례
| 타입 | 사용 사례 | 예시 메트릭 | 설명 |
| :--- | :--- | :--- | :--- |
| **Counter** | 요청 횟수, 에러 수 | `http_requests_total` | 총 요청 수 $\rightarrow$ `rate()` 적용 시 초당 요청 수(RPS) 산출 |
| **Gauge** | 메모리/CPU 사용량, 큐 길이 | `node_memory_MemAvailable_bytes` | 현재 가용 메모리 양 (상승/하강 반복) |
| **Histogram** | API 응답 시간, 요청 크기 | `http_request_duration_seconds_bucket` | 응답 시간이 0.1초 미만인 요청의 비율 계산 |
| **Summary** | 클라이언트 측 지연 시간 | `http_request_duration_seconds` | 95%의 요청이 몇 초 이내에 처리되었는지 확인 |

## 5. PromQL (Prometheus Query Language)

PromQL은 Prometheus의 시계열 데이터를 조회하기 위한 전용 쿼리 언어입니다.

### 5.1 라벨(Label)과 매처(Matcher)
Prometheus 데이터의 핵심은 **라벨(Label)**입니다. 라벨은 메트릭에 부여된 키-값 쌍으로, 데이터를 식별하고 필터링하는 데 사용됩니다.
- **라벨 매처**: `{job="prometheus"}`와 같이 중괄호 내에 조건을 지정하여 특정 라벨을 가진 시계열 데이터만 선택할 수 있습니다. 이를 통해 수천 개의 인스턴스 중 특정 서버나 특정 서비스의 데이터만 정밀하게 추출할 수 있습니다.

### 5.2 데이터 타입
- **Instant Vector**: 특정 시점의 단일 샘플 집합입니다.
- **Range Vector**: 특정 시간 범위 동안의 샘플 집합입니다. `[5m]`와 같이 시간 범위를 지정하여 표현합니다.

### 5.3 쿼리 예시 및 결과
```promql
# 1. 단순 조회: 현재 모든 노드의 CPU 사용률 조회
node_cpu_seconds_total
# 결과: 모든 노드의 CPU 코어별 누적 사용 시간 리스트 출력

# 2. 필터링: 특정 인스턴스의 메모리 사용량 조회
node_memory_MemAvailable_bytes{instance="192.168.0.10:9100"}
# 결과: IP가 192.168.0.10인 서버의 현재 가용 메모리 바이트 값 출력

# 3. 연산 및 함수: 최근 5분간 초당 평균 HTTP 요청 수 계산
rate(http_requests_total[5m])
# 결과: 최근 5분간의 증가율을 계산하여 초당 평균 요청 수(RPS) 출력

# 4. 집계: 모든 인스턴스의 평균 CPU 사용률 계산
avg(rate(node_cpu_seconds_total[5m])) by (job)
# 결과: job 라벨별로 그룹화하여, 해당 그룹 내 모든 인스턴스의 평균 CPU 사용률 출력
```

## 6. 알림 및 시각화 (Alerting & Visualization)

### 6.1 알림 워크플로우
1. **Alerting Rule 설정**: `node_load1 > 5`와 같이 임계치를 설정합니다.
2. **상태 전이**: 조건 충족 시 `Pending` $\rightarrow$ `Firing` 상태로 변경됩니다.
3. **전송**: Prometheus 서버가 Alertmanager로 알림을 전송합니다.
4. **통지**: Alertmanager가 설정된 채널(Slack 등)로 메시지를 발송합니다.

### 6.2 시각화 ([[Grafana]] 연동)
Prometheus 자체 웹 UI는 단순 쿼리 확인 및 디버깅용으로 사용되며, 실제 운영 환경에서는 **[[Grafana]]**를 표준 시각화 도구로 사용합니다.

- **연동 관계**: Prometheus는 데이터의 **수집 및 저장(Backend)**을 담당하고, Grafana는 저장된 데이터를 시각적으로 **표현(Frontend)**하는 구조입니다.
- **연동 방식**: Grafana의 데이터 소스(Data Source) 설정에서 Prometheus 서버의 HTTP URL을 등록하여 API로 데이터를 호출합니다.
- **시각화 장점**:
    - **다양한 패널**: 시계열 그래프, 게이지, 테이블, 히트맵 등 풍부한 차트 제공.
    - **대시보드 공유**: 한 번 구축한 대시보드를 JSON 형태로 내보내거나 팀원과 공유 가능.
    - **동적 필터링**: 변수(Variable) 기능을 통해 드롭다운 메뉴로 서버나 서비스별 데이터를 실시간 전환하며 모니터링 가능.

## 7. 설치 및 빠른 시작 가이드

### 7.1 바이너리 설치 (Linux 기준)
```bash
# 최신 버전 다운로드 및 압축 해제 (v2.45.0 예시, 최신 버전 확인 필요)
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
tar xvf prometheus-2.45.0.linux-amd64.tar.gz
cd prometheus-2.45.0.linux-amd64

# 서버 실행
./prometheus --config.file=prometheus.yml
```

### 7.2 기본 설정 (`prometheus.yml`)
```yaml
global:
  scrape_interval: 15s # 기본 수집 주기

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090'] # 자기 자신 모니터링
  - job_name: 'node_exporter'
    static_configs:
      - targets: ['192.168.0.10:9100'] # 외부 노드 모니터링
```

## 8. 실제 모니터링 적용 사례 (Use Case)

- **[[Kubernetes]] 클러스터 모니터링**: `kube-state-metrics`와 `node-exporter`를 설치하여 Pod의 재시작 횟수, 노드의 자원 고갈 상태, API 서버의 응답 지연 시간을 실시간으로 감시합니다.
- **마이크로서비스(MSA) 성능 분석**: 각 서비스에 Prometheus 클라이언트 라이브러리를 내장하여 API 엔드포인트별 응답 시간(Latency)과 에러율(Error Rate)을 측정하고, 병목 지점을 찾아냅니다.
- **인프라 가용성 체크**: `blackbox_exporter`를 사용하여 외부에서 HTTP/TCP 포트의 생존 여부를 주기적으로 체크하고, 서비스 다운 시 즉시 알림을 받습니다.

## 9. 구축 및 운영 시 고려사항

### 9.1 데이터 보관 주기 (Retention)
Prometheus는 기본적으로 로컬 디스크에 데이터를 저장합니다. `--storage.tsdb.retention.time` 옵션을 통해 보관 기간(기본 15일)을 설정해야 하며, 기간이 길어질수록 디스크 사용량이 증가하므로 주의가 필요합니다.

### 9.2 고가용성(HA) 및 확장성
- **HA 구성**: Prometheus는 기본적으로 단일 서버 구조입니다. 고가용성을 위해 두 대의 서버가 동일한 대상을 수집하도록 구성하여 데이터 유실을 방지합니다. 이때 두 서버 모두에서 알림이 발생하여 **알림 중복**이 일어날 수 있으나, 이는 **Alertmanager의 중복 제거(Deduplication)** 기능을 통해 최종 사용자에게는 하나의 알림만 전달되도록 처리합니다.
- **장기 저장소**: 로컬 디스크의 한계를 극복하기 위해 **Thanos**나 **Cortex**와 같은 외부 저장소 솔루션을 도입하여 데이터를 S3 등에 장기 보관하고 글로벌 쿼리를 수행합니다.
- **성능 최적화**: 너무 많은 라벨(Cardinality)을 사용하면 메모리 사용량이 급증하여 서버가 다운될 수 있으므로, 고유 값이 너무 많은 라벨(예: 사용자 ID, 요청 UUID)은 사용하지 않아야 합니다.