🧐 프로메테우스, '이렇게' 써야 전문가! 애플리케이션 모니터링 베스트 프랙티스

안녕하세요! 👋 프로메테우스(Prometheus)를 도입해서 기본 노드나 데이터베이스 모니터링은 시작하셨나요? 그렇다면 다음 단계는 바로 '우리 애플리케이션에 직접 메트릭 심기', 즉 인스트루멘테이션(Instrumentation)일 겁니다.

 

하지만 막상 시작하려고 하면 "메트릭 이름은 어떻게 짓지?", "어떤 타입을 써야 할까?", "레이블은 막 추가해도 되나?" 같은 고민에 빠지게 됩니다.

 

오늘은 여러분의 고민을 덜어드리고, "프로메테우스 좀 쓸 줄 아네!" 라는 말을 들을 수 있는 애플리케이션 인스트루멘테이션 핵심 베스트 프랙티스를 알기 쉽게 정리해 드릴게요!

---

1. 일관성 있는 이름 짓기: 나중을 위한 최고의 투자 

가장 기본이지만 가장 중요한 규칙입니다. 메트릭 이름이 중구난방이면 나중에 PromQL로 쿼리할 때 큰 혼란이 생깁니다. 아래의 표준 명명 규칙을 따르는 것이 좋습니다.

 

[라이브러리/애플리케이션 접두사]_[측정 대상]_[단위]

• 접두사 (Prefix): 어떤 애플리케이션이나 라이브러리의 메트릭인지 명확히 합니다. (예: http_, prometheus_, api_)
• 측정 대상 (Metric Name): 무엇을 측정하는지 명확하게 나타냅니다. (예: requests_total, request_duration_seconds)
• 단위 (Unit): 메트릭의 단위를 명시합니다. 특히 시간을 나타낼 때는 seconds, 데이터 크기는 bytes 와 같이 기본 단위를 사용하는 것을 강력히 권장합니다. (ms, KB 대신)

✅ 좋은 예:

• api_http_requests_total: API 서버의 전체 HTTP 요청 수 (카운터는 _total 접미사)
• process_resident_memory_bytes: 프로세스의 물리 메모리 사용량 (바이트 단위)
• http_request_duration_seconds: HTTP 요청 처리 시간 (초 단위)

❌ 나쁜 예:

• requests: 무엇의 요청인지 알 수 없음.
• memory: 단위가 없어 MB인지, KB인지 알 수 없음.
• http_latency_ms: 기본 단위가 아닌 밀리초(ms)를 사용함.

---

2. 알맞은 메트릭 타입 선택하기: 올바른 도구 사용 🛠️

프로메테우스에는 네 가지 메트릭 타입이 있습니다. 상황에 맞는 타입을 선택해야 데이터의 의미가 정확해집니다.

• 카운터 (Counter) 📈: 오직 증가만 하는 값에 사용합니다. (예: 누적 요청 수, 누적 에러 수)
  • rate(), increase() 함수와 함께 사용해 '분당 요청 수' 등을 계산합니다.
• 게이지 (Gauge) 🌡️: 값이 오르내릴 수 있는 현재 상태 값에 사용합니다. (예: 현재 접속자 수, CPU 사용률, 큐에 쌓인 작업 수)
• 히스토그램 (Histogram) 📊: 관찰 값의 분포를 파악할 때 사용합니다. 주로 응답 시간(Latency) 측정에 쓰입니다.
  • histogram_quantile() 함수로 "요청의 95%는 몇 초 안에 처리되었나?"와 같은 백분위수(Percentile) 계산에 최적화되어 있습니다. 대부분의 응답 시간 측정에는 히스토그램이 정답입니다.
• 서머리 (Summary) 📝: 히스토그램과 유사하지만, 클라이언트 측에서 직접 백분위수를 계산합니다. 집계가 어려워 특수한 경우 외에는 히스토그램 사용이 권장됩니다.

---

3. ⚠️ 가장 중요! 레이블과 카디널리티 관리하기

레이블(Label)은 프로메테우스의 강력한 기능이지만, 잘못 사용하면 서버를 파괴할 수도 있는 양날의 검입니다. 핵심은 카디널리티(Cardinality)를 관리하는 것입니다.

카디널리티란, 레이블 값의 고유한 조합이 몇 개나 되는지를 나타내는 척도입니다.

• 낮은 카디널리티 (Low Cardinality) 👍: 레이블 값의 종류가 한정적입니다. (예: method="GET", "POST", status="200", "404", "500")
• 높은 카디널리티 (High Cardinality) 💣: 사용자 ID, 이메일, 세션 ID, 요청 ID처럼 무한히 늘어날 수 있는 값을 레이블로 사용하는 경우입니다.

높은 카디널리티는 프로메테우스 서버의 메모리 사용량을 폭발적으로 증가시키고, 성능을 극심하게 저하시키는 주범입니다! 절대로 고유 식별자를 레이블 값으로 사용해서는 안 됩니다.

 

✅ 좋은 레이블

예: http_requests_total{method="POST", path="/api/v1/login", status="200"} (method, path, status는 종류가 한정적입니다.)

 

❌ 절대 피해야 할 레이블

예: http_requests_total{user_id="user12345", session_id="a1b2c3d4e5f6g7"} (사용자가 늘어날 때마다 새로운 시계열(time series)이 무한정 생성됩니다.)

---

4. 무엇을 측정할까? 4대 핵심 지표 (Four Golden Signals) ✨

"그래서 도대체 뭘 측정해야 하나요?"에 대한 최고의 답변은 구글 SRE가 제시한 **'4대 핵심 지표'**입니다. 사용자 경험에 직접적인 영향을 주는 이 네 가지 지표를 중심으로 측정하면 실패하지 않습니다.

1. 지연 시간 (Latency) 🐢: 요청을 처리하는 데 걸리는 시간. 성공한 요청과 실패한 요청의 시간을 구분해서 측정하는 것이 중요합니다.
2. 트래픽 (Traffic) 🚦: 서비스가 받고 있는 요청의 양. (예: 초당 HTTP 요청 수)
3. 에러 (Errors) 💥: 실패한 요청의 비율. 시스템에서 발생하는 모든 종류의 에러를 명시적으로 추적해야 합니다.
4. 포화도 (Saturation) 🈵: 서비스가 얼마나 '가득 찼는지'를 나타내는 지표. CPU, 메모리, 디스크 공간 등 시스템의 가장 제약이 심한 리소스의 부하를 측정합니다.

---

5. 계산은 PromQL에게 맡기기: 애플리케이션은 단순하게 🧠

애플리케이션 코드에서는 복잡한 계산을 하지 마세요. '초당 요청 수' 같은 비율을 계산해서 메트릭으로 노출할 필요가 없습니다.

• 애플리케이션의 역할: 그저 원시 데이터(raw data)를 노출하는 데 집중합니다. 요청이 올 때마다 카운터를 1씩 증가시키기만 하면 됩니다. (http_requests_total.inc())
• PromQL의 역할: rate(http_requests_total[5m]) 처럼 강력한 쿼리 언어인 PromQL을 사용해 원하는 모든 계산, 집계, 분석을 수행합니다.

이렇게 역할을 분리하면 애플리케이션 코드는 단순해지고, 수집된 데이터는 훨씬 유연하게 활용될 수 있습니다.

 

마치며

훌륭한 모니터링 시스템은 잘 구축된 관측 가능성(Observability)에서 시작되고, 그 첫걸음은 바로 올바른 방법으로 메트릭을 심는 것입니다. 오늘 소개해드린 5가지 베스트 프랙티스를 꼭 기억하셔서, 안정적이고 분석하기 쉬운 모니터링 환경을 구축하시길 바랍니다!

---

태그: 프로메테우스, 모니터링, Instrumentation, 베스트 프랙티스, SRE, DevOps, Observability, 카디널리티