대시보드 p90 은 0.48초, 로그는 0.42초였다

목표

같은 요청을 버킷 경계가 다른 두 버전으로 집계해 histogram_quantile 의 추정 오차를 직접 재고, le 를 버린 식·버전을 섞은 식·rate 를 뺀 식이 어떤 숫자를 내는지 확인한 뒤 SLO 에 맞는 버킷을 설계합니다.

왜 중요한가

히스토그램은 표본을 버킷 개수로만 기억합니다. 그래서 분위수는 버킷 안에 표본이 고르게 퍼져 있다고 가정한 선형 보간의 결과이고, 오차의 크기는 순위가 떨어지는 버킷의 폭이 정합니다. 경계 밖으로 나간 꼬리는 아예 보이지 않습니다. 대시보드 숫자가 로그와 다를 때 쿼리를 의심할지 버킷 설계를 의심할지 가를 수 있어야 SLO 를 믿을 수 있습니다.

준비된 환경

python3 /opt/fixtures/pca_histogram_lab.py init 이 /root/pca-histogram/ 에 v2 파드의 요청 로그(access-log-v2.csv)와 README 를 둡니다. 시계열은 http_request_duration_seconds_bucket/_count/_sum 이고 레이블은 route(/checkout, /search), version(v1, v2), le 입니다. v1 은 경계 0.1 0.5 1, v2 는 0.05 0.1 0.2 0.3 0.4 0.5 1 2.5 입니다. 0분부터 60분까지 1분마다 긁었고 지금 시각은 60m 입니다.

python3 /opt/fixtures/pca_histogram_lab.py eval -f 파일 --at 60m 은 lab-k8s 이미지의 promtool 3.0.1 PromQL 엔진으로 표현식을 평가합니다. Prometheus 서버는 띄우지 않으며, 채점기도 같은 엔진으로 여러분의 식과 기준 식을 다시 계산해 적은 숫자와 대조합니다.

단계

1. /root/pca-histogram/access-log-v2.csv 에서 /checkout 의 56분부터 60분까지 요청 100건을 골라, 정렬한 뒤 ceil(q×N) 번째 값(nearest-rank)으로 p90 과 p99 를 구하세요. /root/pca-histogram/01-raw.txt 에 raw_p90= 와 raw_p99= 두 줄(초 단위)로 적습니다. 재료가 없으면 python3 /opt/fixtures/pca_histogram_lab.py init 을 먼저 실행합니다.
2. /root/pca-histogram/02-v1-p90.promql 에 version="v1", route="/checkout" 의 최근 5분 p90 식을 씁니다(histogram_quantile(0.9, ...), rate(...[5m]), le 유지). python3 /opt/fixtures/pca_histogram_lab.py eval -f /root/pca-histogram/02-v1-p90.promql --at 60m 로 결과를 보고 /root/pca-histogram/02-v1.txt 에 v1_p90= 과 error=(v1_p90 에서 raw_p90 을 뺀 값)를 적으세요.
3. /root/pca-histogram/03-v2-p90.promql 에 같은 식을 version="v2" 로 쓰고 결과를 확인합니다. /root/pca-histogram/03-v2.txt 에 v2_p90=, error=(v2_p90 에서 raw_p90 을 뺀 값), closer=(로그의 p90 에 더 가까운 버전 v1 또는 v2)를 적으세요.
4. v1·v2 두 버전의 /checkout 최근 5분 p99 를 eval 로 확인하고, /root/pca-histogram/04-slow.promql 에 v1 /checkout 의 최근 5분 동안 1초를 넘은 요청 수를 increase(..._bucket{le="+Inf"}[5m]) 에서 le="1" 버킷을 빼는 식으로 씁니다(le 값이 달라 매칭 조건이 필요합니다). /root/pca-histogram/04-p99.txt 에 v1_p99=, v2_p99=, slow_requests= 를 적으세요.
5. /root/pca-histogram/05-broken.promql 에 sum by (route) 로 le 를 버린 v2 p90 식을, /root/pca-histogram/05-fixed.promql 에 le 와 route 를 함께 지킨 v2 p90 식을 씁니다. 두 식을 eval 하고 /root/pca-histogram/05-le.txt 에 broken_series=(결과 시계열 수), fixed_series=, search_p90=(/search 의 값)을 적으세요.
6. 카나리 배포 중 대시보드가 version 을 가리지 않고 /checkout 버킷을 합칩니다. /root/pca-histogram/06-mixed.promql 에 version 선택 없이 route="/checkout" 만 고른 p90 식을 쓰고, count by (le) (http_request_duration_seconds_bucket{route="/checkout"}) 로 le 값의 종류를 셉니다. /root/pca-histogram/06-mixed.txt 에 mixed_p90= 과 distinct_le= 를 적으세요.
7. /root/pca-histogram/07-lifetime.promql 에 rate 없이 v2 /checkout 누적 버킷을 그대로 합친 p90 식을 씁니다. /root/pca-histogram/07-lifetime.txt 에 lifetime_p90= 과 window_p90=(03 단계의 최근 5분 v2 p90)을 적어, 31분에 느려진 사실이 어느 쪽에 더 잘 보이는지 비교하세요.
8. /root/pca-histogram/08-buckets.txt 에 새 버킷 경계(오름차순, 유한 경계 10개 이하, +Inf 는 쓰지 않음)를 한 줄로 적습니다. 조건은 세 가지입니다 — SLO 경계 0.3 을 포함하고, 가장 큰 유한 경계가 최대 지연 1.8초 이상이며, 로그 p90 과의 오차가 0.01 이하. python3 /opt/fixtures/pca_histogram_lab.py design 으로 같은 요청을 새 경계로 다시 집계한 결과를 보고 /root/pca-histogram/08-design.txt 에 designed_p90= 과 under_300ms_ratio= 를 적으세요.

참고

• histogram_quantile 은 버킷 안을 선형 보간합니다. 순위가 +Inf 버킷에 떨어지면 가장 큰 유한 경계를 돌려줍니다.
• sum by (...) 에서 le 를 빼면 오류 없이 빈 결과가 나옵니다.
• 흔한 실수: 01 단계에서 보간 분위수(0.425 같은 값)를 적는 것, 04 단계에서 ignoring(le) 없이 빼서 빈 결과를 얻는 것.
• 이 자료는 분마다 같은 분포를 되풀이하는 합성 자료입니다. 오차의 크기는 이 분포에서 잰 값이지 일반 법칙이 아닙니다.
• [Histograms and summaries](https://prometheus.io/docs/practices/histograms/) · [histogram_quantile](https://prometheus.io/docs/prometheus/latest/querying/functions/)

단계 8개

1. 로그에서 진짜 p90·p99 세기
2. 굵은 버킷(v1)이 말하는 p90
3. 촘촘한 버킷(v2)과 비교하기
4. 마지막 유한 경계에 갇힌 p99
5. le 를 버린 대시보드 고치기
6. 경계가 다른 두 버전을 합치면
7. rate 없이 누적 버킷을 읽으면
8. SLO 에 맞춰 버킷을 다시 설계하기