[Chatper 05 | Observability] Prometheus 이해하기

3. Prometheus Data

prometheus data 예제

주석이 없는 부분이 실제 metric 정보

중괄호는 라벨으로 {key = "value"} 형식으로 작성

 

 

3.1 Prometheus data model

프로메테우스 스토리지는 데이터를 time series로 저장함

다만 prometheus 데이터 모델 자체는 time을 가지고 있지 않음

scrap 하는 쪽(프로메테우스 서버)에서 time정보를 기록하여 실제 스토리지에 저장되는 것임

 

 

3.1.1 metric 네임 규칙

# api_http_requests_total is blah blah
api_http_requests_total{method="POST", handler="/messages"} 1.0

metric name

• ASCII letters and digits만 가능
• underscore로 띄어쓰기 구분
• metric name은 convention, guide가 있음

 

label name

• ASCII letters

 

label values

• any Unicode characters

 

자세한 내용은 공식 사이트에서 확인

https://prometheus.io/docs/practices/naming/

Metric and label naming | Prometheus

 

3.1.3  Job & Instance

같은 목적, 또는 같은 일(=같은 어플리케이션)을 하는 대상을 job이라고 함 

job은 여러 개의 instance를 가질 수 있음 

같은 job 내의 여러 instance의 구분은 instance의 이름을 다르게 해서 구성

• job 의 value는 "prometheus_server"
• instance의 value는 "server1", "server2" 등으로 실제 서버의 이름이 올 수 있음
  • 실습에서는 실제 서버의 ip, port,DNS 정보를 instance로 함

 

3.2 Metric 타입

메트릭 정보는 크게 4가지 타입이 있음 

타입마다 사용하는 PromQL이나 대시보드의 형태가 달라짐

 

3.2.1 Counter 

Counter는 축적되는 단방향으로 증가하는 숫자 메트릭

앱이 재기동되면 다시 0부터 시작함

ex)

• number of requests
• number of tasks completed
• number of errors

⚠️ 주의 >>  Counter는 감소하는 숫자로 사용하면 안됨

ex) active thread count (스레드는 만들었다가 사라졌다가 하기 때문에)

 

3.2.2 Gauge

Gauge는 증가하거나 감소할 수 있는 숫자 값을 나타낼 때 씀. (계기판의 숫자 변화를 생각하면 됨)

ex)

• current temperatures
• current memory usage
• active thread count

 

3.2.3 Histogram

Histogram은 관찰 대상에 대해서 sampling해서 버킷별로 구분해서 저장하고 조회할 수 있는 메트릭

ex)

• database I/O latency = 0.99, 0.95, 0.50 percentile (custom)
• response data size = 0.99, 0.95, 0.50 percentile
• 99%, 95%의 시스템에 부정적인 값을 위주로 모니터링. 

히스토그램은 <basename> 을 기준으로 여러개의 time series 를 expose한다.

• cumulative counters for the observation buckets, exposed as <basename>_bucket {le="<upper inclusive bound>"}
• the total sum of all observed values, exposed as <basename>_sum
• the count of events that have been observed, exposed as <basename>_count
  (identical to <basename> _bucket{le="+Inf"} above)

histogram 으로 남은 metric 은 PromQL에서 histogram_quantile() function quantitle을 계산하고

aggregation할 수 있다.

 

metrics에서 histogram type에 대해서 확인해보면

 le = 0.1% 에 해당하는 것 1개, 0.2% 2개.. 등 정보를 확인할 수 있음 

 

3.2.4 Summary

Histogram과 비슷하게 관찰 대상에 대해서 sampling을 함 

뿐만 아니라 관찰 대상에 대한 total count를 제공하고, 모든 관찰값에 대한 sum도 제공

이를 활용해 sliding window에 걸쳐있는 quantitle 정보를 계산할 수 있음

 

 

Histogram과 Summary 중 어떤 것을 선택할 지는 다음 기준을 따름

1. aggregate가 필요하다면 -> Histogram

2. aggregate 필요 X & value의 범위, 분포 보고싶다면 -> Histogram

3. aggregate 필요 X & value의 범위, 분포 X & 정확한 quantile이 필요 -> Summary

 

scrap 하는 metric에 대한 정확한 값을 기대하지 않기 때문에 실무적으로 Histogram을 대부분 사용 

 

 

3.3 PromQL

prometheus metric에 대한 집계 또는 변환 작업을 수행하는 쿼리

실제로 메뉴얼을 찾아보며 사용하는 쿼리로 이를 잘 활용해보자!

 

PromQL을 잘 사용하는 방법은 Grafana에서 대시보드를 만들어가며 

메뉴얼을 보면서 점진적으로 활용도를 늘리는 것이 가장 좋음

3.3.1 Basics

https://prometheus.io/docs/prometheus/latest/querying/basics/

3.3.2 Operators

https://prometheus.io/docs/prometheus/latest/querying/operators/

3.3.3 Functions

https://prometheus.io/docs/prometheus/latest/querying/functions/

3.3.4 Examples

https://prometheus.io/docs/prometheus/latest/querying/examples/

 

---

4. Prometheus Server

 

4.1 Prometheus Architecture

 

• Prometheus server 
  • retrieval : 데이터를 수집
  • storage : 데이터 저장 
  • PromQL : 쿼리를 통해 작업 수행
  • 프로메테우스가 데이터를 수집하는 것은 모두 Pull 방식

 

• Pushgateway
  • shorted-lived jobs에서 push한 데이터를 가지고 있음
  • prometheus 가 pushgateway에 있는 데이터를 pull 해서 scrap함
    scrap한 데이터는 프로메테우스의 로컬에 저장 -> 프로메테우스는 로컬 스토리지 기반의 서버임

 

• Service Discovery
  • 메트릭 데이터를 동적으로 수집할 때 service discovery 프로그램과 연동해야함 

 

• Alertmanager
  • 규칙, 채널들을 관리함 

 

• Grafana
  • PromQL 을 통해 데이터를 조회

4.1.2 Push Gateway

scrap 대상으로 지정할 수 없는 경우 직접 push 할 수 있는 기능

push된 metric은 pushgateway가 보관하고, prometheus는 pushgateway를 scrap해서 데이터를 가져오는 방식

promethues server의 동작 방식에는 변화가 없음

 

다음의 경우에 pushgateway를 사용

• ad-hoc? 하게 잠깐 띄운 서비스인데, promethues에 저장하고 싶은 경우
• service discovery를 하기 힘든 경우

 

❓ ad-hoc이란?

특정 상황에서만 정답이 되고 일반화될 수 없는 해답으로 소위 '하드코딩'(코딩으로 만들어진 솔루션)라고 함

 

 

단, pushgateway는 기본적으로 메모리에 메트릭을 저장하고 있고, 파일로 저장하더라도 로컬 디스크에만 가능

따라서 많은 양의 데이터를 pushgateway에 보내면 안되고, 빈번하게 데이터를 보내면 안 됨

 

pushgateway로의 데이터 전송은 REST API로 호출할 수도 있고, 각 언어의 라이브러리로도 구현 가능

 

4.2 Prometheus의 한계

prometheus 는 기본적으로 로컬 스토리지에 데이터를 구성하고, 해당 데이터를 라벨링 함

그렇다고 클러스터를 구성할 수 있는 아키텍처도 아님

즉, 기본적으로 시간이 지나면 휘발되는 TTL(Time to Live )기반의 데이터가 아니기 때문에 처음부터 대용량을 고려하지 않음

 

따라서 확장성있는 저장소와 그에 맞는 아키텍처의 적용이 필요

현재 가장 안정적으로 사용되는 도구는 Thanos임

 

4.3 Prometheus - Thanos Architecture

 

프로메테우스가 타노스에게 데이터를 전달하고

타노스가 object store(대용량 데이터를 저장할 수 있는 스토어)에 적재하고 관리

즉, 프로메테우스는 scrap하는 역할만 충실히 수행하는 것!

 

 

해당 포스터는 패스트캠퍼스 <한 번에 끝내는 데이터 엔지니어링 초격자 패키지 Online> 강의를 기반으로 작성되었습니다.