[AEWS] #4주차 프로메테우스매트릭과 PromQL (4)

Observability (관측 가능성)

옵저버빌리티(관측가능성)은 시스템 내부 상태를 외부에서 이해하고 분석할 수 있는 능력을 의미하며, 서비스가 어떤 상태인지, 어떤 문제가 발생했는지, 어디서 발생했는지를 파악할 수 있도록 데이터를 수집하고 분석한다.수백~수천 개의 서비스가 분산 환경에서 동작하므로 더 깊이 있는 분석이 필요하여 옵저버빌리티의 중요성이 더욱 높아지고 있다.

 

기존의 모니터링 개념과 비교해보았을 때, 모니터링은 시스템이 정상인지 확인하는 도구로써 지금 CPU 사용량이 높은가에 대한 질문에 답한다면, 옵저버빌리티는 시스템이 왜 그렇게 동작하는지 분석하는 개념으로 CPU 사용량이 높아진 원인은 무엇인가를 파악한다.

즉 옵저버빌리티는 여러 소스의 데이터를 활용하여 시스템 동작의 상관 관계를 파악하고 지속적으로 분석할 수 있는 것을 목표로 둔다.

 

프로메테우스란

 

프로메테우스는 고대 신화에 나오는 신 이름인데 불을 가져다 준 자라는 의미가 지식을 가져다 주는 도구로써 보이지 않는 시스템 내부의 정보를 가져다 준다는 의미를 포함한 것 같다. 다른 오픈소스들도 신화에서 이름을 많이 차용하는 것 같다.

 

프로메테우스는 시계열(time-series) 데이터 기반의 모니터링 및 경고(alerting) 시스템으로 서버, 애플리케이션, 네트워크 장비 등에서 시간에 따라 변하는 데이터를 수집하고 저장한 후, 분석하고 알람을 보낼 수 있는 도구이다.

처음엔 SoundCloud에서 내부 모니터링을 위해 개발되었는데 지금은 CNCF(Cloud Native Computing Foundation) 프로젝트로 성장해서 쿠버네티스(Kubernetes)를 비롯한 클라우드 네이티브 환경에서 많이 사용되고 있다.

 

프로메테우스 매트릭

매트릭은 키-밸류 값으로 저장되어 있으며 표기 방법은 아래와 같다.

<metric name>{<label name>=<label value>, ...}
ex) api_http_requests_total{method="POST", handler="/messages"}

 

 

매트릭 네임, 라벨, 타임스탬프가 키로 저장되고 밸류로 그 시점에서 데이터 값이 저장되는 방식이다.

 

매트릭 타입

카운터

증가하는 값을 저장하는 메트릭 타입

• 주로 이벤트 발생 횟수를 측정할 때 사용
• 사용 예시
  • HTTP 요청 수 (http_requests_total)
  • 프로세스 크래시 횟수 (process_crashes_total)
  • 사용자가 로그인한 횟수 (user_logins_total)

게이지

증가 / 감소하는 값을 저장하는 메트릭 타입

• 현재 상태를 측정하는 메트릭.
• 값이 증가하거나 감소할 수 있음.
• 리소스 사용량을 모니터링할 때 자주 사용됨.
• 사용 예시
  • 현재 사용 중인 메모리 (memory_usage_bytes)
  • CPU 사용량 (cpu_usage_percentage)
  • 현재 활성화된 사용자 수 (active_users)

히스토그램

데이터의 분포를 측정하는 메트릭 타입

• 값의 분포를 버킷(bucket)으로 나누어 저장
• 특정 값 이하인 요청의 개수를 측정할 수 있음
• 평균값(average), 95th, 99th 퍼센타일(percentile) 같은 통계를 계산할 때 사용
• 사용 예시
  • HTTP 요청 지연 시간 (http_request_duration_seconds)
  • 데이터베이스 쿼리 시간 (db_query_duration_seconds)
  • 애플리케이션 응답 속도 (app_response_time_seconds)

서머리

Histogram과 비슷하지만, 직접 값을 저장하는 메트릭 타입

• Histogram과 달리, 미리 계산된 퍼센타일(percentile) 값을 저장
• 개별 요청들의 평균(mean), 최소(min), 최대(max), 퍼센타일(percentile) 등을 계산
• 퍼센타일 값이 이미 계산되어 있으므로 데이터량이 많아지면 부담이 클 수 있음.
• 사용 예시
  • API 응답 속도 (api_response_time_seconds)
  • 사용자 입력 대기 시간 (user_input_delay_seconds)

 

Job, instance

잡은 프로메테우스가 메트릭을 수집하는 대상 그룹으로, 하나 이상의 인스턴스를 포함하는 메트릭 수집 단위이다.

scrape_configs:
  - job_name: "node_exporter"  # Job 이름 (여러 개의 인스턴스 포함 가능)
    static_configs:
      - targets: ["192.168.1.10:9100", "192.168.1.11:9100"]

 

인스턴스는 실제 메트릭을 제공하는 개별적인 엔드포인트로 잡 안에서 개별적으로 모니터링하는 서비스의 실제 서버이다.

scrape_configs:
  - job_name: "web_server"
    static_configs:
      - targets: ["192.168.1.20:8080", "192.168.1.21:8080"]

 

시계열 데이터(Time-Series Data)

시간에 따라 변화하는 데이터를 저장하고 분석하는 방식으로 특정 시간 간격을 두고 연속적으로 관측된 값을 의미한다.

• CPU 사용량 (10시 30분 - 50%, 10시 31분 - 52%)
• 메모리 사용량 (10시 30분 - 4GB, 10시 31분 - 4.2GB)
• 네트워크 트래픽 (10시 30분 - 1Gbps, 10시 31분 - 1.2Gbps)

 

장점

• 시간 기반 분석이 가능 -> 지난 24시간 동안 CPU 사용량이 어떻게 변했는가?
• 추세 예측 가능 -> 트래픽 증가 패턴을 보면 3일 후에 서버가 터질 가능성
• 실시간 모니터링 & 알람 -> 응답 시간이 1초를 넘으면 알람 전송

단점

• 1초마다 데이터를 저장하면 엄청난 양의 데이터가 쌓이게 된다.
• 일반적인 관계형 데이터베이스(SQL)로는 관리가 어렵기 때문에 TSDB가 필요하다.

 

익스포터

프로메테우스 익스포터(Exporter)는 메트릭을 제공하지 않는 시스템에서 데이터를 가져와 프로메테우스가 수집할 수 있도록 변환하는 역할을 하는데, 데이터를 프로메테우스가 이해할 수 있는 형식으로 변환한다.

 

 

즉 익스포터는 외부 시스템에서 데이터를 수집하고, HTTP 엔드포인트(/metrics) 를 통해 데이터를 노출하여, 프로메테우스가 주기적으로(Pull 방식) 데이터를 가져가도록 한다.

나는 주로 노드 익스포터를 사용하여 리눅스 시스템의 CPU, 메모리, 디스크, 네트워크 상태 수집하는 용도로 활용하였었다.

 

CPU 사용량을 측정하는 익스포터 예시는 아래와 같다.

pip install prometheus_client

 

from prometheus_client import start_http_server, Gauge
import psutil
import time

# 게이지 타입의 매트릭 타입
cpu_usage = Gauge("custom_cpu_usage", "Current CPU usage percentage")

def collect_metrics():
    while True:
        cpu_usage.set(psutil.cpu_percent())  # 현재 CPU 사용량을 메트릭으로 설정
        time.sleep(5)  # 5초마다 업데이트

if __name__ == "__main__":
    start_http_server(8000)  # 익스포터 HTTP 서버
    collect_metrics()  # 메트릭 수집

 

이렇게 커스텀으로 생성한 익스포터를 프로메테우스가 수집하도록 설정하려면, prometheus.yaml 파일에 생성한 커스텀 익스포터를 추가해주면 된다.

scrape_configs:
  - job_name: "custom_exporter"
    static_configs:
      - targets: ["localhost:8000"]

 

PromQL

PromQL(Prometheus Query Language)은 프로메테우스에서 메트릭을 검색하고 분석하는 데 사용하는 쿼리 언어로
데이터 필터링, 집계(Aggregation), 변환 등을 수행할 수 있으며, Grafana 대시보드에서 시각화할 때도 사용된다.

 

SQL과 비교해서 보면 좀 더 빠르게 사용이 가능해서 정리하였다.

기능	SQL	PromQL
데이터 조회	SELECT column FROM table;	<metric_name>
조건 필터링	SELECT column FROM table WHERE column = 'value'	<metric_name>{label="value"}
여러 조건 필터	SELECT column FROM table WHERE col1 = 'val1' AND col2 = 'val2'	<metric_name>{label1="val1", label2="val2"}
데이터 그룹화	SELECT column, SUM(value) FROM table GROUP BY column;	sum(<metric_name>) by (label)
집계	SELECT SUM(column) FROM table;	sum(<metric_name>)
집계 + 그룹화	SELECT col, SUM(value) FROM table GROUP BY col;	sum(<metric_name>) by (label)
정렬	SELECT column FROM table ORDER BY column DESC LIMIT N;	topk(N, <metric_name>)
시간 기반 필터링	SELECT column FROM table WHERE time > NOW() - INTERVAL '5 minutes';	<metric_name>[5m]
데이터 증가량	SELECT (column2 - column1) FROM table WHERE time BETWEEN NOW() - INTERVAL '5 minutes' AND NOW();	increase(<metric_name>[5m])
초당 변화율	SELECT (column2 - column1) / time_diff FROM table WHERE time BETWEEN NOW() - INTERVAL '5 minutes' AND NOW();	rate(<metric_name>[5m])
퍼센타일 계산	SELECT PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY column) FROM table;	histogram_quantile(0.95, <metric_name>)

 

promql을 보면서 특히 헷갈렸던.. rate, irate, increase에 대해서 좀 더 자세히 정리해보았다.

3가지 함수 모두 카운터 값을 기반으로 동작한다.

rate (초당 평균 증가율)

 

rate(nginx_http_requests_total[10m]) 함수는 최근 10분 동안의 nginx HTTP 요청 총수 카운터(nginx_http_requests_total)가 초당 얼마나 증가했는지 평균값을 계산한다.

 

[10m]는 최근 10분 동안의 데이터를 포함하는 범위 벡터를 생성하는데 이 벡터에는 지정된 시계열의 여러 시점의 값들이 포함된다.

범위 내의 첫 번째와 마지막 샘플 값을 확인하여 (마지막 값 - 첫 번째 값)을 구하고, 이 값이 전체 시간(10분, 즉 600초) 동안 얼마나 증가했는지를 계산한다.

 

irate (초당 순간 증가율)

 

가장 최근 두 개의 데이터 포인트를 기반으로 초당 증가율을 계산한다.

 

만약 아래와 같이 값이 저장되어 있었다면

• 10:04:00 1500
• 10:05:00 1700

초당 요청 증가율은 (1700 - 1500) / 60초 = 3.33 req/sec 이 된다.

irate로 갑작스러운 급증이나 감소 값을 볼 때 유용하다.

 

increase (지정된 기간 동안의 총 증가량)

 

지정된 시간 범위 동안 전체 증가량(총합)이며 해당 시간동안 얼마나 많은 요청이 발생했는디 분석이 가능하며, 장기간 데이터를 수집할 때 적합하다.