本物のPrometheusにクエリを投げる

한국어 원문으로 표시합니다.

목표

진짜 Prometheus 서버에 쿼리를 던지고 돌아온 숫자를 읽습니다. 이 실습이 끝나면 rate·비율·분위수·예측을 직접 쓰고, 틀렸을 때 왜 틀렸는지 알게 됩니다.

왜 중요한가

PromQL 문법은 하루면 외웁니다. 어려운 것은 돌아온 숫자가 맞는지 판단하는 일입니다. by (le) 를 빠뜨린 histogram_quantile 은 오류를 내지 않습니다 — 그냥 틀린 숫자를 줍니다. 그걸 대시보드에 걸어 두면 몇 달 동안 아무도 모릅니다.

그래서 이 환경에는 12시간치 시계열이 미리 들어 있습니다. 오류가 치솟는 구간이 두 번, p99 만 튀는 구간이 한 번, 단조 감소하는 디스크가 있습니다. 여러분이 쓴 쿼리가 그 사건들을 찾아내는지로 정답을 확인할 수 있습니다.

환경

promq "<PromQL>"      쿼리를 던진다. promq -r 로 원본 JSON
lab-status            무엇이 떠 있는지, 대상이 몇 개인지
tail -40 /var/log/lab-init.log     준비 과정 로그

Prometheus 는 127.0.0.1:9090, 샘플 서비스 exporter 는 9101, node_exporter 는 9100 입니다. Grafana 는 lab-start-grafana 로 켜고 웹 미리보기 3000번 포트로 봅니다.

단계

http_requests_total 에 어떤 라벨이 있는지 찾아 /root/obs/01-labels.txt
초당 요청률 쿼리를 /root/obs/02-rate.promql
5xx 비율 쿼리를 /root/obs/03-errrate.promql
p95 지연 쿼리를 /root/obs/04-p95.promql
시계열이 가장 많은 메트릭 다섯 개를 이름 시계열수 로 /root/obs/05-top.txt
레코딩 규칙을 /etc/prometheus/rules/labhub.yml
설정을 반영하고 새 시계열이 나오는지 확인
디스크 소진 예측 쿼리를 /root/obs/08-predict.promql

참고

쿼리를 파일에 쓰기 전에 promq 로 먼저 던져 보세요. 결과가 비어 있으면 라벨 이름이 틀린 것입니다.
promq 'up' 이 3을 주면 스크레이프가 정상입니다.
결과가 NaN 이면 분모가 0 인 구간을 보고 있는 것입니다.

무슨 시계열이 있는지 먼저 본다

http_requests_total 에 어떤 라벨이 있는지 찾아 /root/obs/01-labels.txt

쿼리를 쓰기 전에 무엇이 있는지부터 봅니다. promq 'count by (__name__)({__name__=~".+"})' 로 메트릭 이름을 훑고, promq 'http_requests_total' 로 라벨을 봅니다. /root/obs/01-labels.txt 에 http_requests_total 의 라벨 이름을 한 줄에 하나씩 적으세요(값 말고 이름만).

초당 요청률

초당 요청률 쿼리를 /root/obs/02-rate.promql

/root/obs/02-rate.promql 에 쿼리를 쓰고 promq "$(cat /root/obs/02-rate.promql)" 로 직접 확인하세요. 스크레이프 간격이 15초이므로 범위는 그 네 배 이상이어야 샘플이 하나만 잡히는 순간이 없습니다. rate 는 sum 안쪽에 있어야 합니다 — 밖에 두면 카운터 리셋을 잘못 처리합니다.

5xx 비율

5xx 비율 쿼리를 /root/obs/03-errrate.promql

/root/obs/03-errrate.promql. 비율이므로 나눗셈이고, 분자·분모 양쪽에 rate 를 걸어야 단위가 맞습니다. 결과가 0.004 근처면 평시, 0.1 을 넘으면 사고 구간을 보고 있는 것입니다 — 이 환경에는 오류가 치솟는 구간이 두 번 들어 있습니다.

p95 지연

p95 지연 쿼리를 /root/obs/04-p95.promql

/root/obs/04-p95.promql. _sum 과 _count 로는 분위수를 못 구합니다. 버킷에 rate 를 걸고 le 라벨을 살린 채로 합친 뒤 histogram_quantile 에 넣습니다. by (le) 를 빼면 오류 없이 틀린 숫자가 나옵니다 — 그래서 더 위험합니다.

시계열이 가장 많은 메트릭 찾기

시계열이 가장 많은 메트릭 다섯 개를 이름 시계열수 로 /root/obs/05-top.txt

카디널리티는 재 봐야 압니다. promq 'topk(5, count by (__name__)({__name__=~".+"}))' 를 던져 보고, 나온 표를 /root/obs/05-top.txt 에 다섯 줄로 옮기세요 — 한 줄에 이름 시계열수, 많은 것부터. 순위는 대상이 더 올라오면 바뀝니다. 그래서 이름 하나가 아니라 그때 잰 표를 남깁니다.

레코딩 규칙 파일 작성

레코딩 규칙을 /etc/prometheus/rules/labhub.yml

/etc/prometheus/rules/labhub.yml 을 만듭니다. groups → rules → record/expr 구조입니다. record 이름은 job:http_requests:rate5m 처럼 수준:메트릭:연산 규약을 따릅니다. 저장한 뒤 반드시 promtool check rules /etc/prometheus/rules/labhub.yml 로 검사하세요.

규칙을 반영하고 새 시계열 확인

설정을 반영하고 새 시계열이 나오는지 확인

Prometheus 를 재시작하지 않고 반영합니다 — curl -X POST http://127.0.0.1:9090/-/reload. 15초쯤 기다린 뒤 promq 'job:http_requests:rate5m' 로 새 시계열이 생겼는지 봅니다. 규칙은 평가 주기마다 계산되므로 즉시 나오지 않습니다.

디스크가 언제 찰지 계산

디스크 소진 예측 쿼리를 /root/obs/08-predict.promql

/root/obs/08-predict.promql. predict_linear 는 '지금 추세가 이어지면 N초 뒤 값' 을 줍니다. node_filesystem_avail_bytes 가 6시간 뒤 0 아래로 내려가는지 묻는 쿼리를 쓰세요. 이 환경의 디스크는 실제로 단조 감소하도록 만들어 두었습니다.