LIT-prometheus-overview

요약

Prometheus는 오픈소스 시스템 모니터링 및 알림 도구로, 시계열(time series) 데이터베이스를 기반으로 메트릭을 수집하고 저장한다. 다차원 데이터 모델, 강력한 쿼리 언어(PromQL), Pull 기반 수집 방식이 핵심 특징이며, 클라우드 네이티브 환경에서 사실상의 표준 모니터링 솔루션으로 자리잡았다.

핵심 포인트

Prometheus 정의와 역사

Prometheus는 2012년 SoundCloud에서 시작된 오픈소스 모니터링 도구이다. 2016년에 Kubernetes에 이어 CNCF(Cloud Native Computing Foundation)의 두 번째 호스팅 프로젝트로 합류했으며, 이후 Graduated 상태로 승격되었다. 현재는 특정 기업에 종속되지 않은 독립 오픈소스 프로젝트로 유지되고 있으며, 대부분의 컴포넌트가 Go 언어로 작성되어 정적 바이너리로 쉽게 빌드 및 배포할 수 있다.

핵심 특징

다차원 데이터 모델: 메트릭 이름과 키-값 레이블 쌍으로 시계열 데이터를 식별한다. 레이블을 통해 동일 메트릭의 다양한 인스턴스를 구분할 수 있으며, 이것이 Prometheus의 "차원적 데이터 모델(dimensional data model)"이다.
PromQL: Prometheus 전용 쿼리 언어로, 다차원 데이터에 대한 필터링과 집계를 유연하게 수행한다.
Pull 기반 수집: HTTP를 통해 대상(target)에서 메트릭을 능동적으로 가져온다(pull/scrape). 단기 작업(short-lived jobs)을 위해서는 Pushgateway를 통한 push 방식도 지원한다.
Service Discovery: 정적 설정 외에 Kubernetes, Consul, DNS, EC2, Azure, GCE 등 다양한 서비스 디스커버리 메커니즘을 지원하여 동적 환경에서 타겟을 자동으로 발견한다.
독립적 서버 노드: 분산 스토리지에 의존하지 않으며, 각 Prometheus 서버가 자율적으로 동작한다. 이 덕분에 인프라 장애 상황에서도 신뢰할 수 있다.

아키텍처

Prometheus 생태계는 여러 컴포넌트로 구성된다:

Prometheus Server: 메트릭을 스크레이핑하고 시계열 데이터를 로컬 TSDB에 저장하는 핵심 서버. 규칙을 실행하여 데이터를 집계하거나 알림을 생성한다.
Exporters: HAProxy, StatsD, Graphite, Node Exporter 등 다양한 서비스의 메트릭을 Prometheus 형식으로 변환하여 노출하는 어댑터.
Pushgateway: 배치 작업 등 단기 프로세스가 메트릭을 push할 수 있게 해주는 중간 게이트웨이.
Alertmanager: Prometheus 서버가 보낸 알림을 수신하여 중복 제거, 그룹화, 라우팅을 처리한다.
Client Libraries: Go, Java, Python, Ruby, .Net, Rust 등 다양한 언어에서 애플리케이션 코드를 계측(instrument)하기 위한 라이브러리.
Service Discovery: 모니터링 대상을 동적으로 발견하는 메커니즘.

전체 흐름: 타겟(또는 Pushgateway) -> Prometheus Server (scrape) -> 로컬 TSDB 저장 -> 규칙 평가 (recording rules, alerting rules) -> Alertmanager (알림 발송) / Grafana (시각화).

데이터 모델

Prometheus의 모든 데이터는 시계열(time series)로 저장된다. 각 시계열은 메트릭 이름과 레이블 집합으로 고유하게 식별된다.

메트릭 유형 (4가지):

유형	설명	용도 예시
Counter	단조 증가만 하는 누적 메트릭. 재시작 시 0으로 리셋 가능	요청 수, 에러 수, 완료된 작업 수
Gauge	임의로 증가/감소하는 단일 수치	온도, 메모리 사용량, 동시 요청 수
Histogram	관측값을 설정 가능한 버킷에 분류하여 카운트. `_bucket`, `_sum`, `_count` 노출	요청 지연 시간, 응답 크기 분포
Summary	관측값의 quantile을 슬라이딩 윈도우에서 계산. `{quantile="<phi>"}`, `_sum`, `_count` 노출	요청 지연 시간의 p50, p90, p99

Histogram과 Summary의 차이: Histogram은 서버 측에서 histogram_quantile() 함수로 quantile을 계산하므로 집계가 가능하지만, Summary는 클라이언트 측에서 quantile을 계산하므로 집계가 불가능하다. 대부분의 경우 Histogram이 더 유연하다.

스토리지

로컬 TSDB: Prometheus는 자체적인 로컬 디스크 기반 시계열 데이터베이스를 내장하고 있다. 2시간 단위의 블록으로 데이터를 압축하여 저장한다.
Remote Read/Write: 외부 장기 저장소와 통합하기 위한 API를 제공한다. Remote Write로 데이터를 외부로 전송하고, Remote Read로 외부 저장소에서 데이터를 읽어올 수 있다.
기본적으로 로컬 저장소는 단기~중기 보존에 적합하며, 장기 보존을 위해서는 외부 스토리지 통합이 필요하다.

Alertmanager와 알림 파이프라인

알림 흐름:

Prometheus Server에서 alerting rules를 평가하여 조건에 맞으면 alert를 생성
생성된 alert를 Alertmanager로 전송
Alertmanager가 중복 제거(deduplication), 그룹화(grouping), 라우팅(routing)을 처리
최종적으로 Email, Slack, PagerDuty, Webhook 등 수신자에게 알림 전달

Alertmanager는 silence(특정 알림 일시 억제)와 inhibition(특정 알림이 활성화되면 다른 알림 억제) 기능도 제공한다.

PromQL 쿼리 언어

PromQL은 Prometheus 전용 함수형 쿼리 언어이다. 주요 기능:

시계열 선택 및 필터링 (레이블 매처)
산술 및 비교 연산
집계 연산 (sum, avg, min, max, count 등)
시간 범위 함수 (rate(), increase(), histogram_quantile() 등)
Recording rules를 통해 자주 사용하는 복잡한 쿼리를 미리 계산하여 저장 가능

Federation

Federation은 하나의 Prometheus 서버가 다른 Prometheus 서버에서 선택된 시계열을 스크레이핑하는 기능이다. 두 가지 주요 패턴이 있다:

Hierarchical Federation: 상위 Prometheus가 하위 서버들의 집계된 데이터를 수집. 대규모 환경에서 확장성 확보.
Cross-Service Federation: 서로 다른 서비스의 Prometheus 서버 간 데이터를 결합하여 통합 뷰를 제공.

Grafana 연동

Prometheus는 자체 Expression Browser를 내장하고 있지만, 실제 운영에서는 Grafana와 연동하여 대시보드를 구성하는 것이 일반적이다. Grafana는 Prometheus를 기본 데이터 소스로 지원하며, PromQL을 직접 사용하여 패널을 구성할 수 있다.

한계점

장기 저장: 로컬 TSDB는 단기~~중기 보존에 적합하며, 수개월~~수년 단위의 장기 저장에는 외부 솔루션이 필요하다.
고가용성(HA): 기본적으로 단일 서버 구조이므로, 고가용성을 위해서는 동일한 설정의 Prometheus를 여러 대 운영하거나 별도 솔루션이 필요하다.
수평 확장: 단일 서버 아키텍처이므로 수평적 스케일링이 어렵다. 대규모 환경에서는 Federation이나 별도 확장 솔루션이 필요하다.
정확도: 100% 정밀한 데이터 수집을 보장하지 않는다. per-request billing 같은 정밀도가 필요한 작업에는 부적합하다.

보완 솔루션

Prometheus의 한계를 보완하기 위한 여러 프로젝트가 존재한다:

Thanos: 장기 저장, 글로벌 뷰, 고가용성을 제공하는 Prometheus 확장 프로젝트. 사이드카 패턴으로 기존 Prometheus에 붙여서 사용.
Cortex: 수평 확장 가능한 멀티 테넌트 Prometheus 장기 저장소. 현재 CNCF 프로젝트.
VictoriaMetrics: 고성능, 저비용의 Prometheus 호환 장기 저장소. 더 적은 리소스로 더 많은 데이터를 처리할 수 있다고 주장.
Mimir (Grafana Labs): Cortex에서 포크된 프로젝트로, 대규모 Prometheus 메트릭 저장 및 쿼리에 최적화.

나의 생각

Prometheus는 클라우드 네이티브 모니터링의 사실상 표준이며, Pull 기반 모델과 다차원 레이블 시스템이 Kubernetes 환경과 자연스럽게 맞물린다. 다만 단일 서버 구조의 한계로 인해 대규모 환경에서는 Thanos나 VictoriaMetrics 같은 보완 솔루션이 거의 필수적이다. LGTM 스택(Loki, Grafana, Tempo, Mimir) 관점에서 보면 Prometheus/Mimir가 메트릭 파이프라인의 핵심을 담당하며, OpenTelemetry와의 통합도 점차 강화되고 있다. RED Method나 USE Method 같은 모니터링 방법론을 실제로 구현할 때 Prometheus의 메트릭 유형과 PromQL이 직접적으로 활용된다.

gonnux.com